| Time |
Nick |
Message |
| 02:12 |
|
sandbergja joined #evergreen |
| 06:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:02 |
|
agoben joined #evergreen |
| 07:10 |
|
rjackson_isl joined #evergreen |
| 07:47 |
|
rfrasur joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:46 |
|
mantis1 joined #evergreen |
| 08:53 |
|
mantis2 joined #evergreen |
| 09:34 |
|
sandbergja joined #evergreen |
| 09:43 |
|
jvwoolf joined #evergreen |
| 09:46 |
|
jvwoolf joined #evergreen |
| 10:44 |
csharp |
so... I had an adventure last night - upgraded PINES to PG 10 and when I re-enabled public access, I got a wall of log errors |
| 10:45 |
csharp |
example: https://pastebin.com/Q0MYfHJz |
| 10:45 |
csharp |
basically, PG 10 changes the way certain functions can return set values within other functions |
| 10:46 |
csharp |
see the 5th bullet point here: https://www.postgresql.org/docs/10/release-10.html |
| 10:46 |
csharp |
https://tapoueh.org/blog/2017/10/set-returning-functions-and-postgresql-10/ helped too |
| 10:46 |
csharp |
so... I spent an additional 3 hours re-upgrading to 9.6 and we're now live on that with no issues |
| 10:47 |
csharp |
planning to gather details for a bug report ASAP, but no one should upgrade to PG 10 until there's a very close look at our SQL |
| 10:49 |
berick |
csharp++ pines++ # trailblazing |
| 10:51 |
csharp |
sooo glad I did the postgres upgrade outside of the EG upgrade window next weekend |
| 10:51 |
csharp |
that would have been hell to untangle |
| 10:56 |
csharp |
the most frustrating part of the ordeal is that we've been testing 3.4 on PG 10 for *months* and have not noticed the issue at all |
| 10:57 |
csharp |
I didn't explicitly run PG unit tests, so possible it would have emerged there |
| 10:57 |
dbs |
csharp++ # thank you for taking that bullet for the rest of us |
| 10:58 |
* csharp |
tips his hat |
| 11:10 |
|
sandbergja joined #evergreen |
| 11:13 |
Bmagic |
csharp++ |
| 11:14 |
Bmagic |
csharp++ # twice because, dang |
| 11:22 |
csharp |
thanks for the sympathy - I think we've all been there |
| 11:23 |
csharp |
also, glad it was me finding it in the middle of the night instead of the next day with all the libraries rolling |
| 11:23 |
Bmagic |
oh for sure! |
| 11:23 |
Bmagic |
nice work |
| 11:56 |
eby |
our 3.3.5 on pg10 seems to be ok so far similar to your 3.4 but i'm sure we have a simpler org/metabib use than pines. we don't expose the stock catalog |
| 11:57 |
eby |
that said was popping in to see if checking out an item should be charging the set deposit amount even if deposit is set to no |
| 11:58 |
Bmagic |
eby: it becomes a "rental fee" in that case |
| 11:58 |
eby |
ah thanks. missed that. had a cataloger accidentally put the replacement price in the deposit on a bunch of things |
| 11:58 |
eby |
bmagic++ |
| 11:59 |
jeff |
eby: yes, sorry, that was added for TADL way back when. we no longer do rentals. ;-) |
| 11:59 |
jeff |
but yes, it's likely still poorly documented. |
| 11:59 |
Bmagic |
I was about to link the doc |
| 11:59 |
eby |
we also no longer do them |
| 11:59 |
jeff |
if there is a deposit amount and no deposit required, then the amount is treated as a rental fee. |
| 12:00 |
jeff |
there are possibly some permissions and there are settings for making profiles exempt, i think. |
| 12:00 |
Bmagic |
I swear I've read the documentation on this somewhere |
| 12:00 |
jeff |
oh, good that there's a doc. i think there was at least a bug calling out the lack of docs. |
| 12:01 |
mmorgan |
eby: We encourage our libraries to hide the deposit amount field in the holdings editor to avoid putting the item price in that field by mistake. |
| 12:01 |
eby |
jeff: related to your comments yesterday the upgrade does help with duplicate transits but we're still getting a bunch attempted which result in a sql duplicate error. Going to try to track down if similar to what you were seeing or if we had a questionable scanner, etc |
| 12:03 |
jeff |
hrm. it looked like the bug comments claimed that the fix included code to prevent duplicate in-flight attempts to check in the same item from a single client. i didn't dig into the patch yet. |
| 12:05 |
jeff |
thanks for the heads up. |
| 12:06 |
eby |
my gut tells me ncip/melcat is involved |
| 12:06 |
eby |
so i'll probably end up bothering you regardless |
| 12:06 |
jeff |
ah. |
| 12:06 |
jeff |
heh. |
| 12:06 |
mmorgan |
We have not had issues with duplicate transits since moving to 3.2, BUT we did have issues when there was already a hanging transit from before the upgrade. We had to identify and cancel hanging transits but haven't had a problem since. |
| 12:07 |
|
Christineb joined #evergreen |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:11 |
eby |
Thanks mmorgan . |
| 12:12 |
jeff |
mmorgan: have you noticed if the duplicate transits were paired, one hold transit and one non-hold transit? |
| 12:14 |
mmorgan |
Hmm. It was a while ago, looking. |
| 12:32 |
|
khuckins joined #evergreen |
| 12:34 |
mmorgan |
jeff: I'm assuming I can tell if this is the case by looking at action.transit_copy.copy_status for same item, same-ish time? First would be 8, second would by 7? |
| 12:36 |
Bmagic |
Is it possible for an index definition to treat two subfields as a single index? Like 810a+810t = one entry? Not sure what happens when either one is missing. Example: //marc:datafield[@tag='810']/marc:subfield[@code='a' or @code='t'] |
| 12:36 |
Bmagic |
can "@code='a' or @code='t'" become "@code='a' AND @code='t'" |
| 12:51 |
|
Dyrcona joined #evergreen |
| 12:59 |
|
collum joined #evergreen |
| 13:11 |
Dyrcona |
csharp: That Pg 10 thing is a known issue, and we have fixed all of the functions that have turned up in testing. Doesn't mean we haven't missed some. Fixes may also not have been backported. |
| 13:19 |
Dyrcona |
Bmagic: Do you want only fields with both the subfield a and t to show up? |
| 13:20 |
Bmagic |
Dyrcona: sure, and I could make an additional definition for just one of them (at another time) |
| 13:20 |
* dbs |
was wondering if the PG10 thing was a difference between the experience of upgrading and a fresh install |
| 13:21 |
Dyrcona |
Well, "or" gets fields with either or both.. "and" will only get records with both. |
| 13:21 |
dbs |
kind of like how we had to manually recreate the three indexes that use UNACCENT (per the release notes) |
| 13:21 |
Dyrcona |
dbs: It could be if you don't apply the upgrades. |
| 13:21 |
Dyrcona |
AFAICT, a fresh install on Pg10 works, with concerto. |
| 13:22 |
Dyrcona |
PG11 and PG12 also seem ok in my very limited tire kicking. |
| 13:22 |
dbs |
Right, I would expect a fresh install to work. But it's the upgrading of an existing system that might be tricky |
| 13:23 |
Dyrcona |
Yeahp. I'm not sure we've made it very clear what functions you have to replace, either. |
| 13:23 |
Bmagic |
Dyrcona: Simple enough. But will the entry be the two fields concatenated? A la metabib.browse_entry.value. - I was planning on setting this up on a test server and trying it out, so no worries |
| 13:23 |
Bmagic |
dbs: I agree, I think it's the upgrade |
| 13:24 |
Dyrcona |
I know it's the upgrade. :) |
| 13:24 |
Bmagic |
:) |
| 13:25 |
Dyrcona |
Bmagic: I'm not so sure about that. I'd have to try it and see what the value comes out to be. You may need some more complicated logic to join the subfield values. |
| 13:26 |
Dyrcona |
dbs: I'm pretty sure you know the answer: I can use just about any short string for cache-busting, rght? Something like today's date, 20200108, would work? |
| 13:40 |
Dyrcona |
Well, doesn't matter, 'cause our custom template apparently doesn't have the cache-busting token in it. |
| 13:40 |
Dyrcona |
BTW, I disagree that 1 year makes any sort of sense for a cache lifetime. |
| 13:44 |
csharp |
Dyrcona: awesome - I did a search on LP for fixes, but didn't see any and decided 9.6 is ok |
| 13:45 |
Dyrcona |
csharp: 9.6 is OK. |
| 13:46 |
csharp |
ah https://bugs.launchpad.net/evergreen/+bug/1730726 |
| 13:46 |
pinesol |
Launchpad bug 1730726 in Evergreen "Support for PostgreSQL 10" [Wishlist,Fix released] |
| 13:47 |
csharp |
I wasn't including Fix released bugs in my searches last night |
| 13:48 |
csharp |
that explains why 3.4 on PG10 is fine |
| 13:50 |
JBoyer |
Ah, ok. So if you *had* done it all in a single night you may have been ok. Not a tradeoff worth taking, necessarily, but at least there's some idea why things went south last night. |
| 13:50 |
csharp |
heh - yep |
| 13:50 |
Dyrcona |
csharp: https://bugs.launchpad.net/evergreen/+bug/1820339 |
| 13:50 |
pinesol |
Launchpad bug 1820339 in Evergreen "Postgres 10 support: Vandelay Edition" [Medium,Fix released] |
| 13:51 |
Dyrcona |
But, yeah.... |
| 13:51 |
JBoyer |
Speaking of bug numbers, if anyone wanted to test bug 1858701 it's real simple and can lead to some really confusing error messages. |
| 13:51 |
pinesol |
Launchpad bug 1858701 in Evergreen "URL modification with regular expressions can lead to 403 Forbidden errors" [Undecided,New] https://launchpad.net/bugs/1858701 |
| 13:51 |
JBoyer |
well, unexpected, anyway. |
| 13:52 |
jeff |
Is anyone here aware of useful workflows for inspecting items on/after checkin, inspecting for missing pieces before capturing for a hold or re-shelving them? |
| 13:53 |
jeff |
Specific case here is holdable kits with many pieces, and wanting to avoid notifying patrons that their item is ready if it isn't all-here, etc. |
| 13:53 |
jeff |
We have in the past used Hold Capture Verify on a shelving location for this. |
| 13:53 |
csharp |
so the order of operations for people not tracking individual bugs and want to upgrade to PG10 would be 1) upgrade Evergreen to the latest point release of 3.3 (minimum) 2) upgrade PostgreSQL to version 10 |
| 13:53 |
jeff |
And that's still probably the most likely thing we'll use. |
| 13:54 |
jeff |
We've also considered checking these items in with "Capture Local Holds as Transits", but the challenge there is that staff would need to remember to turn that on before checkin of these specific items. |
| 13:54 |
jeff |
(or use a dedicated workstation where it's "normally on", etc) |
| 13:55 |
jeff |
Other options include "suppress holds and transits" on the initial checkin. Similar issue there: need to turn it on/off, not simple to "oops, scratch that!" if you forget and capture something to available-for-pickup. |
| 13:56 |
jeff |
Persistent copy alerts with a next-status on checkin are... almost it? I don't think the workflow/features are quite there, but it's potentially promising. |
| 13:56 |
JBoyer |
csharp: yeah, that should be fine. The PG10 changes were tested to be compatible with at least 9.6 (no reason they shouldn't be fine farther back as well) |
| 13:57 |
JBoyer |
But farther back doesn't matter since you can't upgrade to that point without 9.6+ anyway, so it's good. ;) |
| 13:58 |
csharp |
right |
| 13:59 |
csharp |
I think I made the right 1:00 a.m. call :-) |
| 13:59 |
jeff |
Having all items of a certain location/circ_modifier get a status of something like "Staff Review" or "Inspection" on initial checkin, but have it be clearable like a temporary alert on checkin... every time you check the item in you get an alert that it needs to be inspected, but only if it was actually circulating before that, and only until you clear the alert (like a temporary alert), and you'd want |
| 13:59 |
jeff |
checkin to happen but not hold capture (but have hold capture take place once the alert was dismissed, without need to check in again)... |
| 14:00 |
Dyrcona |
I've runt the Pg 10 changes on 9.5. We're upgrading to Pg 9.6 on the 19th. |
| 14:01 |
jeff |
I think Hold Capture Verify is the closest thing we have now, but I'm interested in making something better. I'm especially interested in making something that can be more granular than "all items in this shelving location". |
| 14:04 |
jeff |
Another option is to not check in the items until after inspection. We generally avoid that because it can result in people being unable to check out another item of that same type if there is a circ limit. Also, if there's a day boundary between return and checkin we end up sending overdue notices and/or charging fines (backdating helps after the fact there, and grace intervals could help beforehand). |
| 14:05 |
jeff |
For most other items where we normally inspect (like media), it's mostly checked in initially by an RFID bookdrop or sorter, and those are all "capture local holds as transits". |
| 14:05 |
jeff |
But these multi-part kits (including things like snap circuits, board games, etc) aren't returned via a SIP client (mostly due to their size). |
| 14:11 |
jeff |
There are at least two separate goals, I think: 1) avoid items becoming "ready for pickup" before they have been confirmed as complete, and 2) avoid having items show as Available after Reshelving in a scenario where there's a longer-than-Reshelving-interval delay in inspection (due to weekend, backlog, etc) |
| 14:11 |
jeff |
2 is probably less of a concern, but it would still be neat to have something that covered it as well. |
| 14:12 |
jeff |
Is this something others have given thought to? Have I failed to list other options above? |
| 14:13 |
jeff |
I should probably also consider posting this to a list to reach a wider audience, but brainstorming / drafting here is often useful. :-) |
| 14:26 |
|
lstratton joined #evergreen |
| 14:48 |
mmorgan |
jeff: We delay hold notifications for 30 minutes across the board so staff have that long to get the item on the holds shelf, or retarget the hold if there's a problem. I think you might get some useful feedback by posting it to a list. |
| 14:56 |
jeff |
ah yes, forgot to list those two options: delay of A/T notification (our Text notifications bypass A/T, but we could address that), and/or delay of "available" using the org unit setting Hold Shelf Status Delay / circ.hold_shelf_status_delay. |
| 14:57 |
jeff |
I dislike the granularity of those options, though: at the A/T event def level or the org unit level... |
| 14:57 |
jeff |
But yes, probably more responses from the list. :-) |
| 14:57 |
jeff |
mmorgan++ |
| 15:24 |
eby |
jeff: we do that with tools. everything goes back to staff for inspection, battery charging, etc before it fills holds |
| 15:24 |
eby |
i can try to dig up our current workflow |
| 15:24 |
Dyrcona |
...and cake pans! :) |
| 15:25 |
Dyrcona |
Libraries aren't just about books anymore. |
| 15:30 |
jeff |
eby: thanks! |
| 15:31 |
eby |
jeff: we ended up going with a org unit that all the tools live under. we check it in immediately with hold suppressed i think and it goes in transit to that tools branch. i'd have to dig up the rest of the workflow. but we def get it off the patrons account right away |
| 15:31 |
jeff |
Dyrcona: we used to circ cake pans. recently started doing ao again. |
| 15:32 |
Dyrcona |
Might be nice to have a flag on an item or something to postpone/prevent hold capture. |
| 15:32 |
|
mantis2 left #evergreen |
| 15:33 |
Dyrcona |
But, I'm sure that's the gist of jeff's monologue. :) |
| 15:33 |
jeff |
eby: interesting. did you end up with a workstation associated with the org unit where all tools checkin is done, or use "holds go home" or some other means of preventing holds from going to available without needing to change a setting before checking in those type of item? |
| 15:36 |
eby |
i think both. all the real work is done with a branch workstation. but i think staff also know to change their checkin modifier when handling the items. it has changed a few times so would have to double check. right now we are digging into the booking system for tools like event lightning that patrons want on a specific date |
| 15:36 |
* jeff |
nods |
| 15:45 |
jeff |
Do you have a central tools collection, or are they dispersed among the various branches? |
| 15:45 |
jeff |
I suppose they could also float... |
| 15:45 |
eby |
you can request to any location but they all go to one location for inspection |
| 15:47 |
eby |
they staff there know which cords go with what etc. With the more involved musical stuff we have patrons put the wrong cords into the wrong bags when they have multiple out etc |
| 15:47 |
* jeff |
nods |
| 15:47 |
* alynn26 |
nods also |
| 15:47 |
eby |
battery chargers, etc live there. any batteries are swapped out and charged |
| 15:48 |
eby |
patrons can return to any location though |
| 16:03 |
pastebot |
"Bmagic" at 168.25.130.30 pasted "Index multiple tags results" (16 lines) at http://paste.evergreen-ils.org/10118 |
| 16:03 |
Bmagic |
Dyrcona: see the paste |
| 16:03 |
|
sandbergja_ joined #evergreen |
| 16:05 |
Dyrcona |
Right. What about the last one with a + instead of | ? |
| 16:05 |
Bmagic |
did try that... will do |
| 16:06 |
Bmagic |
indexed nothing |
| 16:06 |
Bmagic |
*didn't* |
| 16:08 |
Dyrcona |
Combining the values of two fields into 1 is a bit beyond the normal use of the indexing code in Evergreen. |
| 16:10 |
Bmagic |
I'm coming to the same conclusion. Though I am contemplating editing the xslt to make the magic |
| 16:10 |
Bmagic |
not sure how though. Just a theory at the moment |
| 16:10 |
Dyrcona |
If I were trying to figure this out, I'd likely dump the marcxml of an example record or two and play with it using a command line xpath tool until I got what I wanted. |
| 16:11 |
Bmagic |
I am sort of doing that but with postgres |
| 16:12 |
Dyrcona |
xslt might be a better choice for what you want to do. My gut says xpath can do it, but it would be complicated. |
| 16:21 |
berick |
Bmagic: there are concat and string-join functions for xpath |
| 16:21 |
Bmagic |
I was looking at https://stackoverflow.com/questions/21996965/concatenate-multiple-node-values-in-xpath/21998154 |
| 16:21 |
Bmagic |
doesn't seem to work when put through Evergreen's PG index functions though |
| 16:26 |
eby |
am i missing something that if i remove the group code for evg 2020 rooms it is $30 cheaper a night |
| 16:32 |
JBoyer |
eby, looks like hotel sites being hotel sites. If I pull up the conf link and a direct link the conference is 11 cheaper, though the "standard" rooms aren't an option. (that's only $15 cheaper for me at the moment) |
| 16:34 |
eby |
k weird. for conference i get 165 . for the same king worklife rooms i get 135-145 depending on including breakfast |
| 16:34 |
eby |
was wondering if some other stuff rolled into that rate |
| 16:35 |
eby |
other than normal requires non-refundable deposit |
| 16:36 |
jeff |
conference codes are often used to credit bookings toward the minimum that the contract with the hotel requires the conference meet. sometimes they also give you the guest additional amenities like free breakfast or wifi. it's annoying if/when the rate is higher than the normal rate. i'd probably call the hotel in that case to inquire. |
| 16:36 |
jeff |
i've no special knowledge of this specific example. |
| 16:36 |
JBoyer |
I just clicked through to the king worklife and it's 170 for me. (206 refundable) |
| 16:37 |
alynn26 |
the non refundable deposit always is cheaper. |
| 16:37 |
jeff |
but it's potentially bad for the conference that attendees doing some comparison may end up booking stays that are not then credited toward the minimum nights that the conference's contract with the hotel may require. |
| 16:37 |
|
khuckins joined #evergreen |
| 16:38 |
JBoyer |
And +1 to what jeff said. Part of what we're getting with a code is a set rate so employers can plan far in advance. |
| 16:38 |
jeff |
(though yeah, the non-refundable might be the differentiator there. i wonder if the hotel can manually credit it toward the conference) :-) |
| 16:39 |
jeff |
(i know some can, not sure if all can) |
| 16:54 |
|
jvwoolf left #evergreen |
| 17:08 |
Bmagic |
berick: string-join(//marc:datafield[@tag='810']/marc:subfield[@code='a'], //marc:datafield[@tag='810']/marc:subfield[@code='t'], " ") crashed the database and went into recovery mode for a few minutes, LOL |
| 17:16 |
|
mmorgan left #evergreen |
| 17:21 |
berick |
Bmagic: yeah, that'll happen if the xpath is not formatted correctly |
| 17:22 |
Bmagic |
yowsa |
| 17:23 |
Bmagic |
(I suppose that xpath is not)? - I had another run where it didn't crash postgres but instead threw an error when reingesting a record (which was nicer than crashing the whole DB) |
| 17:28 |
berick |
Bmagic: string-join((//marc:datafield[@tag='810']/marc:subfield[@code='a'], //marc:datafield[@tag='810']/marc:subfield[@code='t']), " ") |
| 17:29 |
Bmagic |
berick++ |
| 18:00 |
Bmagic |
I'm calling this a bust. But FYI, the string-join and concat functions (with parentheses in the right places) still throw an error during ingest "invalid XPath expression" function metabib.reingest_metabib_field_entries(bigint,boolean,boolean,boolean,boolean,integer[]) line 49 at FOR over SELECT rows |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:04 |
|
sandbergja_ joined #evergreen |
| 19:12 |
|
cmalm joined #evergreen |
| 19:39 |
|
sandbergja_ joined #evergreen |
| 21:19 |
|
sandbergja joined #evergreen |
| 21:46 |
|
sandbergja joined #evergreen |
| 22:10 |
|
cmalm joined #evergreen |
| 22:30 |
|
cmalm joined #evergreen |
| 22:44 |
|
sandbergja joined #evergreen |
| 22:58 |
|
cmalm joined #evergreen |
| 23:20 |
|
cmalm joined #evergreen |
| 23:29 |
|
cmalm joined #evergreen |
| 23:58 |
|
cmalm joined #evergreen |
