| Time |
Nick |
Message |
| 00:26 |
|
mmorgan1 joined #evergreen |
| 00:29 |
|
jeff joined #evergreen |
| 01:46 |
|
dbwells_ joined #evergreen |
| 03:58 |
|
edoceo joined #evergreen |
| 04:02 |
|
Sato`kun joined #evergreen |
| 04:03 |
|
dkyle joined #evergreen |
| 07:29 |
|
collum joined #evergreen |
| 08:06 |
|
akilsdonk joined #evergreen |
| 08:07 |
|
jboyer-home joined #evergreen |
| 08:33 |
|
ericar joined #evergreen |
| 08:43 |
|
Shae joined #evergreen |
| 08:49 |
|
Dyrcona joined #evergreen |
| 08:58 |
|
timf joined #evergreen |
| 08:58 |
|
dkyle left #evergreen |
| 09:00 |
|
kmlussier joined #evergreen |
| 09:19 |
|
tspindler joined #evergreen |
| 09:20 |
|
montgoc1 joined #evergreen |
| 09:23 |
Dyrcona |
So, apparently, join => [ {...}, {...}, ...] doesn't work in JSON queries. |
| 09:25 |
|
rfrasur joined #evergreen |
| 09:27 |
eeevil |
Dyrcona: that's correct |
| 09:27 |
Dyrcona |
'Twould be handy if it did, but I can understand it would get complicated. |
| 09:31 |
|
yboston joined #evergreen |
| 09:33 |
* Dyrcona |
goes back to writing more sensible queries. |
| 09:45 |
|
rjackson-isl joined #evergreen |
| 09:46 |
Dyrcona |
Well, that's interesting.... |
| 09:47 |
Dyrcona |
I did a left join with a first() on the result column, with an array_agg in another column, and when there was more than 1 in the table with the first aggregrate, I get more entries in the array_agg column. |
| 09:47 |
Dyrcona |
I should have expected that. |
| 09:51 |
Dyrcona |
postgresql++ |
| 09:51 |
Dyrcona |
array_agg(distinct table.field) does what I hoped. :) |
| 09:55 |
|
kbeswick joined #evergreen |
| 09:59 |
eeevil |
Dyrcona: did I add aggregate distinct to json_query? |
| 09:59 |
Dyrcona |
eeevil: I was doing the latter with pgsql, not json. |
| 09:59 |
eeevil |
ah, gotcha |
| 10:00 |
Dyrcona |
eeevil: Would you object to my adding action::circulation_with_title to the IDL? |
| 10:00 |
Dyrcona |
It would be basically, a circ row, with title, author, and icon_format. |
| 10:01 |
eeevil |
Dyrcona: oh! I did! ;) {aggregate:true,distinct:true,transform:'first' ...} |
| 10:01 |
Dyrcona |
eeevil: Cool! That is very useful. |
| 10:02 |
eeevil |
Dyrcona: obv, it's missing the icon_format part, but does simple_record (and friends) not work for that? |
| 10:07 |
|
wlambert joined #evergreen |
| 10:10 |
wlambert |
Good morning. I'm not usually one to ask for help, but I'm having some issues with my test installation. In particular I'm having issues installing Business::ISBN from cpan on a fresh 64 bit Ubuntu Precise server. Has anyone else experienced this issue? |
| 10:11 |
pastebot |
"wlambert" at 64.57.241.14 pasted "cpan Business::ISBN Error" (102 lines) at http://paste.evergreen-ils.org/53 |
| 10:12 |
wlambert |
Wow that is neat. That is the output I get from cpan. |
| 10:15 |
Dyrcona |
wlambert: Install it from the package libbusiness-isbn-perl via apt-get. |
| 10:15 |
wlambert |
OK! |
| 10:16 |
csharp |
shouldn't the Makefile.install script handle that? |
| 10:16 |
wlambert |
lol. Looks like it is already installed. |
| 10:16 |
bshum |
csharp: It ought to |
| 10:16 |
wlambert |
It probably did. |
| 10:16 |
Dyrcona |
eeevil: Simple record doesn't really work, because the titles and authors are lower cased, and users don't like that. |
| 10:16 |
wlambert |
I'm so green with this application. I'm trying to follow the install docs to the letter. |
| 10:17 |
* csharp |
uses simple record constantly and our users are now used to it |
| 10:17 |
|
ldw joined #evergreen |
| 10:17 |
csharp |
we get occasional gripes though, mainly from catalogers |
| 10:17 |
Dyrcona |
eeevil: I am basically working on a replacement for the A/T based circ history CSV download, and I want to make an IDL view that can be used in a one shot to get most of the needed information. |
| 10:17 |
csharp |
ah - yeah, patrons wouldn't like that |
| 10:18 |
csharp |
*those* users |
| 10:18 |
Dyrcona |
csharp: I usually only hear complaints from staff, only because most patrons don't know I exist. :) |
| 10:19 |
Dyrcona |
I'm using mafe and mtfe with some nasty joins and aggregates in a test query. |
| 10:19 |
kmlussier |
Dyrcona: That sounds interesting. Is your goal to fix the problem that arises with downloading long circ histories? |
| 10:19 |
Dyrcona |
kmlussier: Exactly that. |
| 10:20 |
Bmagic |
How does Evergreen know which limit_set to choose when there is more than one assocaited with the same matchpoint? |
| 10:20 |
* kmlussier |
concurs that users (staff and public) hate all lower case. |
| 10:21 |
* kmlussier |
looks longingly at https://bugs.launchpad.net/evergreen/+bug/1251394, which would have fixed that problem. |
| 10:21 |
pinesol_green |
Launchpad bug 1251394 in Evergreen "Metabib Display Fields" (affected: 3, heat: 16) [Undecided,New] - Assigned to Bill Erickson (erickson-esilibrary) |
| 10:21 |
bshum |
kmlussier: https://bugs.launchpad.net/evergreen/+bug/1048822 would be happier with better title source too |
| 10:21 |
pinesol_green |
Launchpad bug 1048822 in Evergreen "Simplified Pull List - Need fuller title" (affected: 4, heat: 20) [Wishlist,Confirmed] |
| 10:21 |
* kmlussier |
nods. |
| 10:26 |
csharp |
Bmagic: probably weights, though I can't speak competently to it since we only use a few limit sets |
| 10:26 |
Bmagic |
When defining a limit set, is the "Name" referring to a shelving location name? |
| 10:27 |
Dyrcona |
Bmagic: No, it is the name of the limit set itself. |
| 10:27 |
jeff |
We're sorry, jeff, but your input focus is in another window! |
| 10:27 |
Bmagic |
That's what I thought http://docs.evergreen-ils.org/2.3/_circulation_limit_sets.html is confusing me |
| 10:28 |
Dyrcona |
Bmagic: That's OK. It confuses me, too, and helped to develop and test it. :) |
| 10:28 |
Bmagic |
Really, there is nothing about the definition of a limit set that means anything as far as the type of item or patron ect. The only thing that really means anything is the maximum items out |
| 10:29 |
Dyrcona |
Bmagic: The limit set is more a place holder. The names mean what you want them to mean, and should be related to what the rules actually do. |
| 10:29 |
* Dyrcona |
will look at his own for examples. |
| 10:29 |
* kmlussier |
thinks she has seen more complete documentation on limit sets somewhere. |
| 10:30 |
Dyrcona |
kmlussier Bmagic: Here, maybe: https://jason.mvlcstaff.org/looking-glass/ |
| 10:30 |
kmlussier |
No, I was thinking of this http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=docs/circ_limits.txt;h=32c233d0ec88ed40745811f715f0f5f17b57f86a;hb=HEAD |
| 10:30 |
csharp |
wlambert: oh - so you were installing those cpan modules during the DB configuration step? |
| 10:30 |
kmlussier |
Looks like it was never added to roots.txt |
| 10:31 |
Dyrcona |
Well, maybe not. |
| 10:32 |
wlambert |
Yes. I think I may have misunderstood the install instructions. I followed the section about installing Postgres on the same server and it looks like the cpan section was for when Postgres is installed on a standalone server? |
| 10:32 |
Dyrcona |
Yeah. That's not in the docs? |
| 10:33 |
Dyrcona |
wlambert: Right. You need some of the perl stuff if you run the database on its own server. |
| 10:33 |
csharp |
wlambert: correct - install those modules if you're installing the DB separately. They will already be there if you've installed Evegreen |
| 10:33 |
bshum |
wlambert: Fwiw, that section needs some love anyways now that more stuff is packaged and not needing to be installed from CPAN. That said, I could see value in a short paragraph explanation of what a "standalone PostgreSQL server" is |
| 10:34 |
csharp |
plus, it would be nice to recommend installation from OS packages rather than CPAN (where possible) |
| 10:34 |
csharp |
"if you're on debian/ubuntu, do 'sudo apt-get install ....'" |
| 10:34 |
wlambert |
I realized what I'd missed as soon as you guys started commenting. I really appreciate the help! |
| 10:34 |
bshum |
csharp: Well as of 14.04, all them are packages (which I tested myself when we setup our new standalone DB server) |
| 10:35 |
Dyrcona |
csharp: Sometimes O/S packages are broken. |
| 10:35 |
bshum |
csharp: I've been curious to know how Jessie is, but I think Wheezy isn't quite there. |
| 10:35 |
* Dyrcona |
gives the horde "maintainer" for Debian/Ubuntu the hairy eyball. |
| 10:36 |
|
akilsdonk joined #evergreen |
| 10:36 |
wlambert |
We have a very small college library. Do any of you guys see a problem running the DB on a single server in production? |
| 10:36 |
csharp |
Dyrcona: I've seen way more breakage with CPAN than with OS packages, but general point taken |
| 10:37 |
Dyrcona |
wlambert: Define "very small college library" in terms of # of items, staff, students, and general use. |
| 10:37 |
bshum |
wlambert: I know a few places who run everything on the same server. Generally it's a matter of the resources available on the server (CPU, RAM, hard disk space) that are useful to take into account when deciding how to leverage different installation approaches. |
| 10:37 |
csharp |
plus, CPAN is still a hurdle to OS packaging efforts for EG, so as long as we use it, we're hurting the effort to standardize installation efforts |
| 10:37 |
bshum |
And also yes, all the things Dyrcona said about how small you are :) |
| 10:37 |
wlambert |
We have 3 on our library staff and about 1200 students. |
| 10:38 |
csharp |
s/one of those 'efforts'/a good synonym/ |
| 10:38 |
wlambert |
I'm really not sure how many items they have. I know they've seen a lot of growth since they started adding ebooks. |
| 10:38 |
Dyrcona |
wlambert: How many circulations/month or year or whatever? |
| 10:39 |
Dyrcona |
*I* always recommend running the database on its own, dedicated hardware server. I recommend that for any database application when you can, not just for Evergreen. |
| 10:39 |
csharp |
wlambert: +1 to what Dyrcona just said |
| 10:40 |
* jeff |
avoids packaging discussions out of habit |
| 10:40 |
csharp |
you don't want to go live on an all-in-one server and have to scale out later in an emergency situation |
| 10:41 |
Dyrcona |
So, jeff, you're not volunteering to be the official Debian maintainer for Evergreen? |
| 10:41 |
wlambert |
We have about 150 circulation transactions a month. |
| 10:41 |
jeff |
Dyrcona: are people still considering that as an option/goal? |
| 10:42 |
jeff |
wait, I said I AVOIDED these discussions. :P |
| 10:42 |
csharp |
despite having broached the subject, I'm not willing to die on the packaging hill today, but I do look out for minimizing obstacles in the way when I see them ;-) |
| 10:42 |
wlambert |
And we have about 354,000 materials volumes. |
| 10:42 |
jeff |
leave the system perl alone, use perlbrew and cpanm. :-) |
| 10:42 |
* csharp |
would at least like us to go the way of Koha and eventually have our own deb repo |
| 10:43 |
Dyrcona |
wlambert: Well, you probably could get away with an all-in-one server, but I'd make it kind of beefy, like 64GB or more of RAM with SSD for storage. |
| 10:43 |
jeff |
(i don't actually yet advocate that for evergreen, since i haven't tried it for the full system, even in test/dev) |
| 10:43 |
csharp |
even if we're not looking for full exception |
| 10:43 |
jeff |
my preferred debian mirror has disappeared from DNS. :P |
| 10:43 |
jeff |
this is mildly annoying. |
| 10:43 |
csharp |
s/exception/Debian acceptance/ |
| 10:44 |
csharp |
dunno what I was thinking there ;-) |
| 10:44 |
Dyrcona |
We run our own Ubunut and CPAN mirrors mainly for our own use. |
| 10:44 |
Dyrcona |
Ubunut! Hah! |
| 10:44 |
bshum |
Appropriate some days |
| 10:44 |
csharp |
@who is an Ubunut? |
| 10:44 |
pinesol_green |
ldw is an Ubunut. |
| 10:44 |
Dyrcona |
Where's Alfred Jarry when you need him? |
| 10:45 |
* Dyrcona |
actually makes that typo quite a bit. |
| 10:46 |
* eeevil |
read's up |
| 10:47 |
bshum |
That's a decent number of materials. |
| 10:47 |
wlambert |
Dyrcona: Thanks! |
| 10:50 |
|
akilsdonk joined #evergreen |
| 10:51 |
eeevil |
Dyrcona: fwiw, the "display fields" stuff will make that much easier down the road ... not sure if it's worth waiting on that or not. There's working code, though: https://bugs.launchpad.net/evergreen/+bug/1251394 |
| 10:51 |
pinesol_green |
Launchpad bug 1251394 in Evergreen "Metabib Display Fields" (affected: 3, heat: 16) [Undecided,New] - Assigned to Bill Erickson (erickson-esilibrary) |
| 10:51 |
Dyrcona |
Yep. that was mentioned earlier. |
| 10:51 |
|
jboyer-home_ joined #evergreen |
| 10:52 |
Dyrcona |
eeevil: What do you think of the idea of adding a view for circs with title info to the IDL, though? I'm trying to find a way to get the data that is faster than what I've been getting from a serious of JSON queries. |
| 10:52 |
Dyrcona |
s/serious/series/ |
| 10:54 |
eeevil |
no serious objections. my only concern is that a (potentially) transient idl "view" could leak into reports, and would constitute cruft we need to maintain if it becomes obsolete. of course, the potential-ness is an open question -- it might be relatively permanent |
| 10:56 |
Dyrcona |
Yes. I want to experiment with it being SQL defined in the IDL versus a view in the database. |
| 10:56 |
csharp |
I know our reports runners would love to see "non-normalized" title and author info in reports |
| 10:57 |
csharp |
fwiw |
| 10:57 |
Dyrcona |
My plan is also to only support 2.6+ because it will use MVF data. |
| 10:57 |
|
jboyer-home_ joined #evergreen |
| 10:58 |
eeevil |
csharp: it'll still be normalized (fwiw), just not quite so normalized ;) |
| 10:59 |
Dyrcona |
I plan to use mafe and mtfe, since I've already got that working in my query. |
| 10:59 |
csharp |
oh - no biggie in any case ;-) PINES users are used to the all lowercase appearance at this point |
| 11:34 |
wlambert |
Sorry to bust in on your high level ruminations with yet another greenhorn conundrum but I've searched for an answer to this and have failed: Exception: OpenSRF::EX::Session 2014-05-30T10:21:52 OpenSRF::Transport /usr/local/share/perl/5.14.2/OpenSRF/Transport.pm:83 Session Error: router private.ils01.cumberland.edu/open-ils.cstore IS NOT CONNECTED TO THE NETWORK!!! |
| 11:34 |
wlambert |
|
| 11:35 |
wlambert |
srfsh will answer my math problem |
| 11:36 |
wlambert |
and my opensrf_core_xml file looks ok to me. |
| 11:36 |
wlambert |
I can ping private.ils01.cumberland.edu because I've added entries to my /etc/hosts file |
| 11:37 |
|
geoffsams joined #evergreen |
| 11:37 |
wlambert |
I guess I should say that I get that error when doing the autogen.sh -u |
| 11:38 |
wlambert |
Do you guys have any ideas what I might have missed? |
| 11:41 |
Dyrcona |
wlambert: Did you restart services after installing evergreen again? |
| 11:41 |
Dyrcona |
wlambert: What version of OpenSRF and Evergreen did you install? |
| 11:43 |
csharp |
wlambert: and you did replace the OpenSRF opensrf.xml with the Evergreen opensrf.xml, right? |
| 11:43 |
Dyrcona |
csharp++ |
| 11:43 |
wlambert |
LOL |
| 11:44 |
wlambert |
csharp I'm not sure I did replace that file correctly. your comment made me think of something that didn't make sense to me at the time. let me go back into the docs and try something. |
| 11:46 |
pinesol_green |
[evergreen|Dan Pearl] LP#1321363: Suppress Hold Transit use elicits client error - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b102ce2> |
| 11:49 |
bshum |
dbwells: FYI, I closed out the milestones for 2.5.5 and 2.6.1 |
| 11:49 |
bshum |
And added new ones for the next |
| 11:50 |
dbwells |
bshum: I was intending to wait until they were live on the downloads page, but that's fine. Thanks. |
| 11:50 |
bshum |
Well I just had a feeling somebody might try pushing more code |
| 11:50 |
bshum |
And wanted milestones around for it |
| 11:51 |
dbwells |
It's an inexact science :) |
| 11:53 |
|
akilsdonk joined #evergreen |
| 11:56 |
pinesol_green |
[evergreen|Jeff Davis] LP#1284832: Add missing seed data: enable combined search for only the subject class by default - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=53b5adf> |
| 11:57 |
dbwells |
bshum: I'm going to go ahead and do a few of the other post build steps now (mark things "Fix Released", move unfinished stuff). |
| 11:57 |
bshum |
dbwells++ |
| 12:02 |
wlambert |
So I installed OpenSRF 2.3 and Evergreen 2.6. I was a big dummy and didn't copy over the new .example files as csharp pointed out. |
| 12:02 |
wlambert |
the autogen script ran flawlessly once I did...imagine that. |
| 12:03 |
wlambert |
Thanks again for the help/direction |
| 12:04 |
Dyrcona |
wlambert++ |
| 12:09 |
wlambert |
I did run eg_db_config but without the database creation stuff. |
| 12:12 |
csharp |
wlambert: excellent |
| 12:13 |
wlambert |
I'm in! *pumped* |
| 12:23 |
bshum |
Hmm, if the new selfcheck uses JS for many things, including logout, if there any reason we shouldn't use a JS solution to solve the auto-timeout using the library setting for selfcheck patron timeout? |
| 12:24 |
* bshum |
is still pondering https://bugs.launchpad.net/evergreen/+bug/1306814 |
| 12:24 |
pinesol_green |
Launchpad bug 1306814 in Evergreen "Self checkout ignoring patron timeout library setting" (affected: 3, heat: 14) [Medium,Confirmed] |
| 12:27 |
bshum |
In fact, I wonder if there's anything salvageable from the old selfcheck UI's JS that we could use. |
| 12:38 |
pastebot |
"jboyer-home" at 64.57.241.14 pasted "Two holds permit checks, both alike in dignity, in Holds.pm where we set our scene..." (9 lines) at http://paste.evergreen-ils.org/54 |
| 12:39 |
jboyer-home |
I saw a report today of a hold capturing an item on checkin that could not possibly pass the hold permit check. (Hold required a transit, this circ mod never transits) That paste shows the last 2 holds permit checks of the transaction. |
| 12:40 |
jboyer-home |
Has anyone else seen an entry like that in their logs? (checking hold Fieldmapper::action….. instead of checking hold 1234) |
| 12:46 |
Dyrcona |
jboyer-home: Yes, I see a lot of them. |
| 12:47 |
Dyrcona |
jboyer-home: It means the function was called with a full, field mapped ahr object, not just a database id. |
| 12:49 |
jboyer-home |
I found where that log line is printed and assumed it was something like that (We had a lot of trouble with similar issues because we used circ scripts for so long) Do you have a lot of questions about seemingly “impossible” holds captures, or are they not causing you problems there? |
| 12:49 |
Dyrcona |
jboyer-home: I don't think that would cause the impossible hold captures. It's more likely a case of you have a hold matrix matchpoint that is triggered when you don't expect it to. |
| 12:51 |
jboyer-home |
I tested the item and usr by hand with action.hold_permit_test and it failed, as it should. It’s possible that rsyslog lost the rest of the transaction I suppose, but I’m at a loss as to what might have happened. |
| 12:53 |
Dyrcona |
Dunno. Holds are complicated. |
| 12:54 |
jboyer-home |
Yeah, I’m trying to dig into it here, I was just hoping someone would say “Oh that, check this out: etc.” |
| 12:55 |
mmorgan |
jboyer-home: is it possible that the item was edited after capture? Just grasping at straws... |
| 12:58 |
jboyer-home |
We checked the auditor tables and the only entries are the status changing from available to in transit to reshelving (transit aborted) |
| 12:59 |
jboyer-home |
Which makes me think it may have been on the holds pull list now, because I thought it was checked out, not available. |
| 12:59 |
Dyrcona |
Yeah, aborting a transit sets to reshelving. |
| 13:00 |
|
bmills joined #evergreen |
| 13:00 |
|
hbrennan joined #evergreen |
| 13:01 |
jboyer-home |
I’ll have to investigate further after lunch. Perhaps some time and food will lead me closer to an answer. |
| 13:01 |
mmorgan |
jboyer-home: Capture local holds as transits checkin modifier? |
| 13:40 |
hbrennan |
Setting up Patron Self-Registration... what time format should the Expire Interval be in? I'm positive it can't be in seconds, but I have no idea how else to write something in the Value field |
| 13:43 |
bshum |
Hmm |
| 13:43 |
hbrennan |
uh-oh |
| 13:43 |
hbrennan |
:) |
| 13:43 |
bshum |
I've never seen that setting before :) |
| 13:43 |
hbrennan |
There aren't any examples in the doc or in the staff client |
| 13:44 |
hbrennan |
I know it's for how long after the patron self-registers does it stick around in the staff client for finishing up |
| 13:44 |
hbrennan |
so I've heard people do a few weeks or a month |
| 13:46 |
Dyrcona |
hbrennan: something like 1 month or 1 year, or 2 weeks, or so should work. |
| 13:47 |
hbrennan |
Plain english? That sounds too easy :) |
| 13:47 |
hbrennan |
Evergreen is so smart |
| 13:47 |
Dyrcona |
That's postgresql's interval type. |
| 13:48 |
hbrennan |
Perfectly reasonable, which is why it has thrown me off |
| 13:48 |
bshum |
I just wonder if the setting needs " or ' around it |
| 13:48 |
hbrennan |
Dyrcona++ |
| 13:48 |
bshum |
Interval I mean |
| 13:49 |
|
jihpringle joined #evergreen |
| 13:49 |
bshum |
Looking at staging.purge_pending_users() in the DB I guess. |
| 13:50 |
bshum |
Eh, it'll probably be okay. |
| 13:50 |
bshum |
:) |
| 13:51 |
bshum |
Aha, so the UI applies the interval with " " around it when it stores it to the table. And then the function takes those off and casts it to Interval |
| 13:51 |
bshum |
Cool |
| 13:52 |
eeevil |
bshum: setting values are stored as JSON, thus "" ... that makes it a JSON string |
| 13:52 |
bshum |
Yep, slowly understanding |
| 13:52 |
hbrennan |
And it doesn't specifically say SELF in the settings such as GUI: Require day_phone on patron registration..... |
| 13:53 |
hbrennan |
but it seems those settings are specific to the self registration in OPAC |
| 13:53 |
hbrennan |
In my humble opinion, those GUI settings could use the addition of "self" |
| 13:53 |
Dyrcona |
hbrennan: No, I think those settings affect the staff client, too. |
| 13:53 |
hbrennan |
Ack |
| 13:53 |
bshum |
Well, that setting is in category group OPAC |
| 13:54 |
bshum |
The require one is in group GUI? |
| 13:54 |
Dyrcona |
The GUI ones affect the staff client. |
| 13:54 |
hbrennan |
There aren't settings like those under OPAC |
| 13:55 |
hbrennan |
In the example in the doc, the OPAC view of the self-registration screenshot shows phone, email, date of birth |
| 13:55 |
hbrennan |
but they aren't in the out-of-the-box version |
| 13:55 |
hbrennan |
and those options (phone, email) aren't listed in the OPAC Library Settings |
| 13:56 |
hbrennan |
I think I need to take good notes to help out these this documentation |
| 13:57 |
hbrennan |
I'm guessing adding phone and email can only be added directly in the db then? |
| 13:58 |
* bshum |
has never used the patron self-registration feature before |
| 13:58 |
bshum |
So.... hmm |
| 13:59 |
* bshum |
assumes you turn it on via library settings first |
| 13:59 |
hbrennan |
I think I need to summon bott |
| 13:59 |
jeff |
pretty sure that _bott_ and grpl are like tadl and do not use the Evergreen self-reg form for patrons. |
| 14:00 |
jeff |
TADL uses the API to submit pending patrons, and uses the staff-side bits to turn them from pending into real patrons, but doesn't use the built-in form that patrons fill out. |
| 14:00 |
hbrennan |
That wouldn't surprise me |
| 14:01 |
hbrennan |
But what is stumping me is that the documentation example shows phone and email, and talks about using the GUI settings to add those things |
| 14:01 |
hbrennan |
but it doesn't make sense |
| 14:01 |
hbrennan |
"Several existing Library Settings can be used to determine if a field should be required or hidden in the self-registraion form:" |
| 14:02 |
hbrennan |
then it lists all the GUI such as GUI: Require day_phone field on patron registration |
| 14:02 |
bshum |
Hmm |
| 14:02 |
bshum |
Open-ILS/src/templates/opac/register.tt2 is what's used for the self-reg form right? |
| 14:03 |
hbrennan |
yes |
| 14:03 |
jeff |
yes, and OpenILS::WWW::EGCatLoader::Register looks up the org unit settings and validates. |
| 14:03 |
bshum |
To prevent any of these fields from showing locally, regardless org unit settings, simply remove the fields from this list. |
| 14:03 |
bshum |
That's what it says in the comments, it's not customized on your system to not include day_phone, etc. for some reason |
| 14:04 |
hbrennan |
My template has county and dob and phone and email |
| 14:05 |
hbrennan |
but they aren't displaying in the OPAC |
| 14:05 |
hbrennan |
weird...er |
| 14:05 |
hbrennan |
So my db template looks like the example screenshot |
| 14:05 |
bshum |
And "GUI: Show day_phone on patron registration" is set to TRUE in the settings? |
| 14:05 |
hbrennan |
but the real-life OPAC view isn't |
| 14:05 |
hbrennan |
I haven't messed with the GUI, since it sounded like they were overall settings for the staff client too |
| 14:06 |
bshum |
Indeed |
| 14:06 |
jeff |
DIG/docs contributors could probably use a means of saying "can I get a developer to verify what this actually does as I'm trying to document it?" -- other than just IRC. Because I'm pretty sure there's room for improvement here, and I just don't have the immediate cycles to dig into it. |
| 14:07 |
jeff |
the self-reg form makes use of the existing org unit settings to determine fields to display/etc, but it does override some fields to force them to display, like first/second/family name, street1/street2/city/post_code/usrname |
| 14:08 |
jeff |
actually it uses "force" in the comment, but reading it it looks like it's just defaulting them. |
| 14:09 |
hbrennan |
Okay, well set DOB GUI setting to true and now it's showing on the OPAC |
| 14:09 |
hbrennan |
and it was already in the template |
| 14:09 |
hbrennan |
so the GUI setting is for self-registration, not just staff client end |
| 14:10 |
* Dyrcona |
is not surprised that they affect both. |
| 14:10 |
jeff |
That's what I said! :-) |
| 14:10 |
bshum |
Well that's what the docs would lead me to believe: http://docs.evergreen-ils.org/2.6/_patron_self_registration.html |
| 14:10 |
bshum |
That the GUI settings would affect self registration |
| 14:11 |
hbrennan |
jeff: But Dyrcona guessed the opposite first |
| 14:11 |
bshum |
But they already affected staff client |
| 14:11 |
hbrennan |
:) |
| 14:11 |
Dyrcona |
No, I did not. I simple stated that the GUI settings affect the staff client. |
| 14:11 |
hbrennan |
so shouldn't all those settings in GUI benefit from the addition of "self"? |
| 14:11 |
Dyrcona |
I made no speculation that they work or not in the OPAC. :) |
| 14:11 |
hbrennan |
Because in our system, DOB is already required in the staff client side |
| 14:12 |
jeff |
hbrennan: there's a mis-match between the defaults in the staff client and the defaults in the patron self-registration interface when it comes to some fields. |
| 14:12 |
hbrennan |
so that setting, GUI: Require dob in patron registration was ONLY affecting the OPAC self-registration end |
| 14:12 |
hbrennan |
When it was set to false, we still couldn't register a patron without DOB... and when set to true it showed in the OPAC |
| 14:14 |
Dyrcona |
hbrennan: Was it set to false, or was it not set? |
| 14:14 |
hbrennan |
Roger that, not set |
| 14:14 |
Dyrcona |
See what jeff said a couple of lines above. |
| 14:15 |
Dyrcona |
So, if the field isn't set, a default will be used. |
| 14:15 |
hbrennan |
I am going to print out this whole conversation and digest it |
| 14:16 |
jeff |
The settings interface / description of the settings might be enhanced by describing that they are used for both the in-client registration and the patron self-registration interfaces. |
| 14:16 |
bshum |
Hmm, so basically the issue is that Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Register.pm doesn't include default show for things like phone, dob, email while the screenshot in the docs do? |
| 14:16 |
hbrennan |
yes |
| 14:17 |
jeff |
And either specify their individual defaults there, or bring the defaults into line with each other (arguably that would result in unexpected behavior at upgrade time). |
| 14:17 |
hbrennan |
The first thing I did was turn on the OPAC: Allow patron self-registration |
| 14:17 |
hbrennan |
and then was immediately confused because it didn't look like the first page of the doc |
| 14:17 |
Dyrcona |
or, make a whole new set for self-registration, 'cause you might want them to be different for some reason. |
| 14:17 |
bshum |
Yeah I just did that on my master server just to see the results too |
| 14:17 |
bshum |
YAOUS-- |
| 14:17 |
hbrennan |
I like different |
| 14:17 |
bshum |
Or YAOUS+- I guess |
| 14:17 |
bshum |
:\ |
| 14:18 |
jeff |
Dyrcona: and for extra confusion, refer to the GUI ones when the self-reg ones aren't set. ;-) |
| 14:18 |
Dyrcona |
jeff: And vice versa! |
| 14:18 |
hbrennan |
changing the GUI to required then requires it for OPAC and staff client |
| 14:18 |
jeff |
Dyrcona: oof. |
| 14:18 |
Dyrcona |
"Time to change seats!" "Move down!" |
| 14:18 |
bshum |
Maybe we should create a new group category then for these settings :D |
| 14:18 |
hbrennan |
so at least now I see why I would want to use suggest instead of require |
| 14:18 |
hbrennan |
brb |
| 14:20 |
hbrennan |
back |
| 14:20 |
hbrennan |
sorry, I'm on the circ desk now |
| 14:24 |
|
jenny_ joined #evergreen |
| 14:24 |
jenny_ |
Hello.... I have problem in 2.5.4 Evergreen Ubuntu Distro. when I try to renew Item it's always show NO_MATCHPOINT |
| 14:25 |
jenny_ |
what is it? |
| 14:26 |
hbrennan |
Thank you jeff++ Drycona++ and bshum++ |
| 14:26 |
bshum |
jenny_: That sort of error usually means that the system was unable to find a matchpoint in the circulation policies to match for applying the correct values for duration, etc. for the renewal. |
| 14:26 |
hbrennan |
I'll experiment and get back to you |
| 14:27 |
bshum |
A common issue is that the existing rules are defined too narrowly and may be missing a detail. |
| 14:27 |
bshum |
Like an existing rule might say Renewal is False, in which case, it won't use that rule when someone does a renewal. |
| 14:27 |
jenny_ |
I didn't do anything in rules... I don;t change or delete or add rules |
| 14:27 |
bshum |
You may wish to check the rules in your circulation policies to find out what they say then. |
| 14:27 |
bshum |
Or ask someone who does have the control over that for your system. |
| 14:29 |
jenny_ |
I am the only one who control my system... This morning some customer say's they can;t renew there items in the website so I check and yea they right |
| 14:29 |
jenny_ |
There is no error code etc but it say's no_matchpoint |
| 14:29 |
jenny_ |
If ever I create new rule? |
| 14:29 |
jenny_ |
what to do? |
| 14:30 |
jenny_ |
should I delete the old rule? |
| 14:30 |
Dyrcona |
jenny_: No. Deleting rules won't help. |
| 14:30 |
jenny_ |
and create new rule? |
| 14:30 |
jenny_ |
hmmm... so what should I do? Create new rule? |
| 14:31 |
Dyrcona |
jenny_: I would make a new rule. Leave everything empty except for the circ duration and fine rule if you charge fines. |
| 14:31 |
Dyrcona |
@praise 2 bshum |
| 14:31 |
* pinesol_green |
bshum is kind and patient to newbies |
| 14:32 |
bshum |
jenny_: Or check your existing rules and see if the renewal option is set to something like "false" |
| 14:32 |
bshum |
Maybe it should be "unset" if you want the same rules to apply to both renewals and regular checkouts. |
| 14:32 |
Dyrcona |
bshum++ |
| 14:33 |
jenny_ |
renewal is true |
| 14:33 |
Dyrcona |
jenny_: I'd probably have to see your actual rules. |
| 14:34 |
jenny_ |
Can I have your email? so I can send you some screenshot later? |
| 14:34 |
Dyrcona |
no_matchpoint means the system can't find a rule that applies to the current circulation. |
| 14:34 |
Dyrcona |
You could paste them somewhere and put links in the channel. |
| 14:34 |
Dyrcona |
Then others could see them, too. |
| 14:36 |
jenny_ |
Everything works fine week's ago only this day I didn't do anything in the system specially the circ policies |
| 14:36 |
Dyrcona |
jenny_: Are you the only one who uses the system? |
| 14:36 |
jenny_ |
yes |
| 14:37 |
Dyrcona |
Have you renewed this particular item for the same patron before? |
| 14:37 |
jenny_ |
I think yes... no customer complain about renewal of the item only this morning... |
| 14:38 |
Dyrcona |
jenny_: It's a good idea to a "default" rule, one with just about everything empty except the duration. |
| 14:38 |
jenny_ |
I never touch my system for a week. |
| 14:38 |
Dyrcona |
OK. I believe you. I'm trying to help you renew the item. |
| 14:39 |
jenny_ |
if I create new rule that's consider as default rule, right? I just leave some fields empty |
| 14:40 |
Dyrcona |
Sort of. The system goes from most to least specific, so if you have something that could match anything that becomes a de facto default. |
| 14:40 |
jenny_ |
Ok... I'll be back later. to ask again... :) thanks for the idea |
| 14:41 |
kmlussier |
@praise Dyrcona |
| 14:41 |
* pinesol_green |
Dyrcona can run a report without assistance |
| 14:42 |
bshum |
jenny_: If it's quiet here later (today is Friday and the weekend is coming), feel free to post some of the details of your issue to the general mailing list for further feedback. Seeing some of your rules may shed light on the situation. |
| 14:42 |
* bshum |
can't believe it's Friday already. |
| 14:42 |
Dyrcona |
Well, a Monday holiday will do that to you. |
| 14:43 |
jenny_ |
You guys go for weekend? |
| 14:43 |
Dyrcona |
For most of us, yes. |
| 14:43 |
Dyrcona |
I'll be hanging around, though. |
| 14:43 |
jenny_ |
ohhh.... so what;s general mailing? |
| 14:44 |
jenny_ |
this one? "http://paste.evergreen-ils.org/" |
| 14:44 |
bshum |
Well, no, there are email mailing lists that the community uses for communications. |
| 14:44 |
bshum |
They're listed out on http://evergreen-ils.org/communicate/mailing-lists/ |
| 14:46 |
jenny_ |
I hope someone will answer me there. |
| 14:46 |
Dyrcona |
Well, we've pretty much told you how to fix it here. |
| 14:46 |
Dyrcona |
To find out why you're rules are not working as you think, we'd need to see them. |
| 14:46 |
Dyrcona |
I have used http://inky.ws/ for posting screen shots before. |
| 14:48 |
bshum |
~lists information on the Evergreen project's mailing lists is available here: http://evergreen-ils.org/communicate/mailing-lists/ |
| 14:48 |
pinesol_green |
But lists information on the evergreen project's mailing lists already means something else! |
| 14:48 |
jenny_ |
Ok I will post my Screenshot there And how I will paste them and send? |
| 14:48 |
bshum |
~no lists information on the Evergreen project's mailing lists is available here: http://evergreen-ils.org/communicate/mailing-lists/ |
| 14:48 |
pinesol_green |
I'll remember that bshum |
| 14:48 |
bshum |
~lists |
| 14:48 |
pinesol_green |
information on the Evergreen project's mailing lists is available here: http://www.evergreen-ils.org/listserv.php |
| 14:48 |
bshum |
Good |
| 14:48 |
bshum |
Wait that's wrong |
| 14:48 |
bshum |
Dangit |
| 14:49 |
bshum |
Err |
| 14:50 |
bshum |
~no lists is information on the Evergreen project's mailing lists is available here: http://evergreen-ils.org/communicate/mailing-lists/ |
| 14:50 |
pinesol_green |
I'll remember that bshum |
| 14:50 |
bshum |
~lists |
| 14:50 |
pinesol_green |
lists is information on the Evergreen project's mailing lists is available here: http://evergreen-ils.org/communicate/mailing-lists/ |
| 14:50 |
jenny_ |
thanks guys... :* <3 |
| 14:51 |
jenny_ |
i'll be back to you again <3 |
| 14:51 |
jenny_ |
to all of you |
| 15:23 |
kmlussier |
I never use the clear holds shelf button and have a quick question about it. When I click to View Clearable Holds, I see Canceled holds, which I would expect. But when click to "Clear these Holds," it doesn't clear the canceled holds from the interface. |
| 15:23 |
kmlussier |
Is it supposed to work that way? |
| 15:24 |
mmorgan |
I think so, because the hold has already been cancelled. The next step is to check them in. That's my perception, anyway. |
| 15:25 |
kmlussier |
Yes, I just expected it to disappear from the screen just like the ones that have reached their expiration date. |
| 15:26 |
jeff |
kmlussier: when you clear expired holds using that method, do the copies go Reshelving/Available or do you still need to check them in to clear their "on holds shelf" status? |
| 15:26 |
jeff |
(shelf-expired holds) |
| 15:26 |
kmlussier |
My recollection is that you still need to check them in. But let me check. |
| 15:27 |
jeff |
because from what I remember, that's ALL you have to do with cancelled holds -- you check them in, nothing special, and they clear their on hold shelf status and either get captured for another hold or go to reshelving / in-transit, etc. |
| 15:27 |
mmorgan |
I don't think the "Clear" function acts on the cancelled ones at all, since they are already cancelled. |
| 15:28 |
kmlussier |
OK, that makes sense then. It just surprised me. |
| 15:28 |
jeff |
i think the shelf expired and cancelled holds are shown in the same interface because in the case of both of them you probably want to go pull them from the hold shelf |
| 15:28 |
jeff |
seems that the name of the display as well as the "these" in the button you mention are not entirely accurate, though. :-) |
| 15:28 |
kmlussier |
jeff: Yes, exactly. I do remember when cancelled holds weren't showing there, and how frustrating it was for users. |
| 15:29 |
mmorgan |
jeff: yes, there was a lot of confusion with the "Clear these holds" among our users initially. |
| 15:29 |
mmorgan |
some thougt they could select a number of holds and clear just those |
| 15:29 |
kmlussier |
I'm sure it's not an issue for anyone else. I just happened to be in there looking at something entirely different. Which I will now return to. :) |
| 15:30 |
jeff |
we have a report for cancelled holds on shelf, and we use the color of the adhesive hold slip to pull holds, so we don't use that interface. |
| 15:31 |
jeff |
(seven different colors of sticky paper, one for each day. is it tuesday morning? go pull all the items with an orange slip.) |
| 15:31 |
jeff |
(six day hold shelf expiry) |
| 15:32 |
mmorgan |
wow! That's a lot of sticky paper. Is that in addition to printed hold slips? Or are the hold slips printed on the sticky paper? |
| 15:32 |
kmlussier |
I find that interface very difficult to work with when there are a lot of holds on the shelf. It takes a long time to load and, if I try to scroll down too quickly, the system starts throwing error messages at me. I can see why you might want to use sticky paper. |
| 15:32 |
jeff |
(longer or shorter hold shelf expiry requires more/fewer colors of paper, but then the colors change days and it gets more complex) |
| 15:32 |
jeff |
mmorgan: hold slips are printed on the sticky paper, sticky paper is placed over the opening of the book, books are shelved spine facing away. |
| 15:33 |
jeff |
kmlussier: yes. pulling all of a certain color then scanning them with the "clear shelf-expired holds" modifier meant that staff stopped having to load a long list of holds and select specific ones to cancel. |
| 15:34 |
jeff |
transit slips are printed to plain receipt paper, not sticky. this is where printer contexts come in handy. :-) |
| 15:43 |
|
akilsdonk joined #evergreen |
| 15:43 |
jboyer-home |
Dyrcona: It turns out you were right about the holds matrix and my earlier issue. The patron that placed the hold in question was using a special type of staff account that can do “anything” as far as holds and circs are concerned. The answer was obvious once we noticed that. |
| 15:46 |
|
wlambert_ joined #evergreen |
| 15:46 |
rjackson-isl |
Dyrcona++ |
| 15:46 |
rjackson-isl |
jboyer-home++ as well! :-) |
| 15:49 |
|
wlambert__ joined #evergreen |
| 16:18 |
wlambert__ |
For a guy who doesn't ask for help I know I've been needy today but you guys are awesome. I'm tring to add a new patron and I keep getting the following: Event: 2001:DATABASE_UPDATE_FAILED -> The attempt to write to the DB failed |
| 16:19 |
wlambert__ |
I've checked the database and my evergreen user has ownership of my evergreen database. |
| 16:19 |
wlambert__ |
I've filled out the required fields. The only odd thing I see is that the 'Home Library' field only has Example Consortium even though I've configured my org structure. |
| 16:20 |
wlambert__ |
Any ideas? I've googled my hair out. |
| 16:20 |
bshum |
wlambert__: When you say that you've configured your org structure, do you mean that you've added new organizational units? |
| 16:20 |
bshum |
Or edited existing ones |
| 16:21 |
bshum |
Because whenever you make changes like that, you have to run autogen.sh and restart apache |
| 16:21 |
bshum |
For the changes to apply |
| 16:21 |
bshum |
My first guess is that the example consortium org unit 1 does not allow users to be registered to that unit |
| 16:21 |
wlambert__ |
bshum, yes thats what I wanted to say. I couldn't recall the terminology fast enough for my fingers. |
| 16:21 |
wlambert__ |
lol |
| 16:22 |
bshum |
And it's not giving you a very nice answer on why it's not adding the user, but it isn't |
| 16:22 |
wlambert__ |
OH well, I edited the root OU then added a sub OU |
| 16:23 |
Dyrcona |
wlambert__: Did you run autogen.sh after making the changes? |
| 16:24 |
wlambert__ |
doing it now |
| 16:24 |
wlambert__ |
restarted apache and i just got back in. |
| 16:24 |
Dyrcona |
bshum++ # beat me to it, I see. |
| 16:25 |
wlambert__ |
Do I need to restart anything other than apache once I've run the autogen.sh? |
| 16:26 |
Dyrcona |
Usually, no. |
| 16:27 |
wlambert__ |
Hm. I'm still seeing the same behavior with no changes. |
| 16:28 |
wlambert__ |
Should I also be able to add a new root OU under Organizational Units in the tree? |
| 16:28 |
wlambert__ |
When I try that I get no action on the 'New Child' button. |
| 16:32 |
jboyer-home |
wlambert__: check /etc/apache2/eg_vhost.conf and make sure that the OSRFTranslatorCacheServer is the address of a valid and running memcached server. |
| 16:32 |
|
jboyer-home left #evergreen |
| 16:33 |
|
jboyer-home joined #evergreen |
| 16:34 |
Dyrcona |
wlambert__: Have you checked the postgresl log or did I miss that? |
| 16:34 |
wlambert__ |
Hm. OSRFTranslatorCacheServer is the localhost IP 127.0.0.1 on port 11211. |
| 16:34 |
wlambert__ |
but it is commented out. |
| 16:37 |
|
tspindler left #evergreen |
| 16:40 |
pastebot |
"wlambert__" at 64.57.241.14 pasted "postgre log entry" (5 lines) at http://paste.evergreen-ils.org/56 |
| 16:41 |
Dyrcona |
Yep. It tried to create a patron with no home library. |
| 16:41 |
Dyrcona |
You chose one from the drop down, or was it empty? |
| 16:42 |
bshum |
wlambert__: When you ran autogen and restarted apache, did you also restart your Evergreen client as well? |
| 16:43 |
bshum |
(maybe not exiting / starting the client again may not have fully fleshed out the home library options) |
| 16:43 |
wlambert__ |
I did, but I'm going to step through it all again. |
| 16:43 |
|
jboyer-home left #evergreen |
| 16:44 |
wlambert__ |
JOHN BROWN |
| 16:44 |
wlambert__ |
The home library field only had the default/not valid consortium option |
| 16:45 |
wlambert__ |
I swear I checked after restarting apache and reloading my client but when I went back in to get the text from that box to send you (the exact default name in home library) I see my new org settings in the dropdown. |
| 16:45 |
csharp |
gmcharlt: (or others) does the debian/ubuntu package libmarc-xml cover the same libs as MARC::File::XML? |
| 16:45 |
wlambert__ |
Thanks guys! |
| 16:45 |
gmcharlt |
csharp: yes |
| 16:46 |
csharp |
gmcharlt: excellent - thank you |
| 17:07 |
|
mmorgan left #evergreen |
| 17:13 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:32 |
|
Dyrcona joined #evergreen |
| 18:34 |
Dyrcona |
Shucks. |
| 18:35 |
Dyrcona |
jboyer-* is not around. |
| 18:35 |
Dyrcona |
Not sure which I should later. |
| 18:37 |
Dyrcona |
@later jboyer-isl You said on 2014-05-20 at 10:17 EDT: 'Sigh. on restore (of a 2.5.2-ish db) is anyone seeing this error: COPY failed for table "z3950_index_field_map": ERROR: new row for relation "z3950_index_field_map" violates check constraint "valid_z3950_attr_type"'. That answer would be 'Yes' as of right now. |
| 18:37 |
pinesol_green |
Dyrcona: If all else fails, try this: http://en.wikipedia.org/wiki/Rubber_duck_debugging |
| 18:37 |
Dyrcona |
@later tell jboyer-isl You said on 2014-05-20 at 10:17 EDT: 'Sigh. on restore (of a 2.5.2-ish db) is anyone seeing this error: COPY failed for table "z3950_index_field_map": ERROR: new row for relation "z3950_index_field_map" violates check constraint "valid_z3950_attr_type"'. That answer would be 'Yes' as of right now. |
| 18:37 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 18:53 |
|
ldw joined #evergreen |
| 18:55 |
|
Dyrcona joined #evergreen |
| 18:55 |
Dyrcona |
I should have just stayed in the channel. |
| 18:56 |
Dyrcona |
@later tell jboyer-isl I think it happens because the function for the check contraint is in the evergreen schema. |
| 18:56 |
pinesol_green |
Dyrcona: The operation succeeded. |
| 18:57 |
Dyrcona |
Not gonna try fixing it, now, 'cause no one is paying me to fix it now. |
| 19:00 |
hbrennan |
Good thinkin |
| 19:18 |
Dyrcona |
I'll give it a shot on Monday. Should be simple, just drop the constraint and recreate it with the schema as part of the function name. |
| 19:24 |
bshum |
Dyrcona++ |
| 19:59 |
hbrennan |
# The dojo date widget in the patron edit UI only accepts default # values in ISO8601 format. It will not accept locale-shaped dates. |
| 19:59 |
hbrennan |
++ to whomever wrote this comment into opac/register.tt2.... I wrote this question down to myself minutes ago, and there's the answer right in the db |
| 20:04 |
Dyrcona |
hbrennan: That would have been berick. |
| 20:05 |
hbrennan |
Ah, thanks. I do like him. |
| 20:05 |
hbrennan |
I actually wish there was a signature at the top/bottom of every database page |
| 20:05 |
hbrennan |
just for fun |
| 20:05 |
hbrennan |
Sometimes there are great comments |
| 20:06 |
hbrennan |
or even Easter Eggs |
| 20:06 |
Dyrcona |
I used git blame to find out. |
| 20:06 |
hbrennan |
:) |
| 20:06 |
Dyrcona |
git blame will tell you the last person to edit a line. |
| 20:07 |
Dyrcona |
If you use it repeatedly, you can even find out who added a line to a file. |
| 20:07 |
hbrennan |
I wouldn't want to use a blame tool for good! :) |
| 20:07 |
Dyrcona |
:) |
| 20:08 |
Dyrcona |
Usually, when I try to use it to figure out whom to blame for something, I find my name. |
| 20:08 |
Dyrcona |
;) |
| 20:08 |
hbrennan |
Haha, oops |
| 20:08 |
Dyrcona |
As for the error that jboyer-isl and I get, I wonder why it started being an issue recently. |
| 20:09 |
Dyrcona |
Unless the oils_xpath fixes in the 0874 upgrade script have something to do with it. |
| 20:10 |
hbrennan |
I hope you're just thinking out loud because you've lost me |
| 20:11 |
Dyrcona |
I am. |
| 20:11 |
hbrennan |
I'll listen then |
| 20:12 |
Dyrcona |
We number the main upgrade scripts beginning at 0001.{blah}.sql |
| 20:13 |
Dyrcona |
So, by 0874, I mean a file named 0874.function.oils_xpath-tweaks-for-newer-pg.sql |
| 20:14 |
Dyrcona |
And, it turns out, that 2.5.2 doesn't have that upgrade, so that can't be the one. |
| 20:14 |
hbrennan |
Sleuthing |
| 20:14 |
Dyrcona |
Yeah, I'm just curious why it shows up now. |
| 20:15 |
Dyrcona |
I didn't get the error a month ago. |
| 20:16 |
hbrennan |
And you didn't upgrade? |
| 20:16 |
hbrennan |
Or you did? |
| 20:17 |
Dyrcona |
We upgraded on May 11. |
| 20:17 |
* jeff |
looks at 0874 |
| 20:17 |
Dyrcona |
jeff: It can't be 0874 if it shows up in 2.5.2 |
| 20:18 |
Dyrcona |
So, before May 11, we didn't get this message when restoring a database. |
| 20:18 |
jeff |
I'm looking at 0874 because I'm curious, because I've dug into search path issues before and mostly come to the conclusion that fully-qualifying the function calls is the only way to be happy. |
| 20:18 |
Dyrcona |
ok. |
| 20:18 |
Dyrcona |
That's my plan for resolving this constraint issue. |
| 20:18 |
jeff |
essentially because no matter your username or database search path or user/session/etc search path, pg_restore always clobbers the search path on restores. |
| 20:19 |
Dyrcona |
yep. |
| 20:20 |
jeff |
and since there's really little benefit to relying on the search path to find evergreen functions, i don't feel bad using fully qualified calls in Evergreen. seems preferable to trying to argue for pg_restore to change. ;-) |
| 20:20 |
Dyrcona |
I don't think it has anything to do with the upgrade scripts making changes. |
| 20:20 |
Dyrcona |
jeff++ |
| 20:20 |
Dyrcona |
0795 was the last one to touch that constraint, and we've had it since last summer at least. |
| 20:21 |
Dyrcona |
Which makes me wonder why it suddenly pops up now. |
| 20:22 |
jeff |
do you know when it started happening for jboyer? |
| 20:24 |
Dyrcona |
He mentioned it on 5/20 . |
| 20:24 |
Dyrcona |
I noticed with a restore to my dev database this evening. |
| 20:25 |
Dyrcona |
Maybe its a pg client issue. |
| 20:27 |
jeff |
perlbrew use perl-5.20.0 |
| 20:27 |
jeff |
cpanm Mojolicious |
| 20:27 |
Dyrcona |
jeff: Wrong window? |
| 20:27 |
* jeff |
plays around with new versions of old toys |
| 20:28 |
Dyrcona |
Anyway, I've probably spent more time just looking it why it happens than I would have spent if I actually fixed it. |
| 20:30 |
hbrennan |
I'm trying to figure out why my coworker often get some message about "positive numbers" when generating predictions.... |
| 20:30 |
hbrennan |
She can never recreate it for me, and I've never seen such a message |
| 20:31 |
hbrennan |
There are many mysteries in EG |
| 20:32 |
Dyrcona |
Yeah. We don't use serials, so I have no idea why she'd get such messages. |
| 20:33 |
hbrennan |
I manage them, and do more things in that module than anyone.. and in 14 months have never seen it |
| 20:34 |
hbrennan |
That's the biggest mystery to me |
| 20:34 |
hbrennan |
I just want to recreate it! I don't care so much why it happens |
| 20:34 |
Dyrcona |
:) |
| 20:35 |
jeff |
I'm not surprised when I can't re-create something, and often find that I do something sligtly different out of habit than what was done by the person reporting the problem. But when even the person reporting the issue can't reproduce it, that gets frustrating. :-P |
| 20:35 |
hbrennan |
Yep |
| 20:36 |
hbrennan |
and since it seems to be harmless (she just closes out and it works the next time), it's low on my list |
| 21:21 |
|
artunit joined #evergreen |
| 21:35 |
|
ldw joined #evergreen |
| 21:59 |
hbrennan |
Happy weekend everyone. Good night. |
| 23:46 |
|
remingtron joined #evergreen |
| 23:46 |
|
mtcarlson_away joined #evergreen |
| 23:47 |
|
vlewis joined #evergreen |
| 23:49 |
|
RBecker joined #evergreen |
| 23:53 |
|
edoceo_ joined #evergreen |
