Evergreen ILS Website

IRC log for #evergreen, 2022-07-13

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
07:16 rjackson_isl_hom joined #evergreen
07:33 collum joined #evergreen
07:35 collum joined #evergreen
07:49 mantis1 joined #evergreen
07:50 rfrasur joined #evergreen
08:20 BDorsey joined #evergreen
08:23 dbriem joined #evergreen
08:41 rjackson_isl_hom joined #evergreen
08:42 mmorgan joined #evergreen
09:03 jvwoolf joined #evergreen
09:24 Dyrcona joined #evergreen
10:16 dbriem joined #evergreen
10:41 dbriem joined #evergreen
10:57 gmcharlt_ berick: I'm probably missing something, but prior to your patch for 1975879, was there any workflow that actually triggered "Change Circ Lib When Owning Lib Changes" ?
11:03 berick gmcharlt_: yes, modifying owning lib in the copy attrs tab
11:05 gmcharlt_ ah, I get it now
11:09 gmcharlt_ berick: I wonder if, upon changing the owning library on the call number, it should pop up a modal asking how to handle linked items
11:09 berick gmcharlt_: i could see that
11:10 gmcharlt_ I can also imagine edge cases. e.g., change the call number owning library, then change the owning library on one or more of the items currently in the editing session ... then figure out how changes should be reconciled
11:11 gmcharlt_ particularly in the always cascade to all linked items case
11:13 gmcharlt_ also, if you've got any patch review tuits today, I'd like to suggest egbug 1956986
11:16 berick gmcharlt_: yes, can do
11:16 gmcharlt_ berick++
12:14 berick Bmagic++ # just saw your earlier comment.
12:15 berick working on cleaning up the branch now
12:18 Dyrcona Crazy. I'm still seeing the discrepancy in 856 display on this test vm compared to production, and I can't find the difference in the code.
12:28 Dyrcona Hmm.... Looks like the difference may be in the database. 856$3 shows up in asset.uri.label in the test db but goes in asset.uri.use_restriction in production.
12:28 Dyrcona But! The database code should be identical since the test db was restored from a dump on Sunday.
12:29 collum joined #evergreen
12:29 mmorgan Dyrcona: Is there a difference in the function biblio.extract_located_uris?
12:34 Dyrcona mmorgan: I'll check but there shouldn't be. It's a restored dump, both on Pg 10.
12:35 Dyrcona One is on Ubuntu 18.04 and the other on Ubuntu 20.04, so that might be it, but I would have figured that I'd have noticed this before then.
12:40 Dyrcona I dumped the function definitions from both databases and diffed them. They are the same.
12:41 Dyrcona So, my production behavior is wrong according to the function definition.
12:47 Dyrcona But, how.....
12:48 Dyrcona I have only 1 biblio.extract_located_uris, so there's not one with a different signature hanging around.
12:51 Dyrcona According to the db function, $Z or $2 should go in use_restriction and $y or $3 should go into label. My production db entries look like $y or $z is in label and $3 is in use_restriction.
12:53 Dyrcona My old entries in the test database look like production, but when I update them, they get the "correct" values. I'm going to see if I can find some that were recently added. I suspect we had a hacked version of the db function that didn't make it through an upgrade.
12:55 Dyrcona Too bad I don't have any really old dumps hanging around....
12:55 Dyrcona Hmm... I'll check the training server it might be old enough.
12:55 Dyrcona mmorgan++
12:58 Dyrcona Well, the training function definition is the same and the db dump sitting there from my last refresh is post our most recent upgrade.
13:00 Dyrcona I think we had a custom version of that function that got overwritten in our latest upgrade. I know we had some custom OPAC code related to the display of 856s that predates my arrival at CWMARS.
13:00 mmorgan Dyrcona: bug 1482757 changed the function for 3.7.3
13:00 pinesol Launchpad bug 1482757 in Evergreen 3.7 "Loading records with located URIs should not delete and recreate call_numbers" [Low,Fix released] https://launchpad.net/bugs/1482757
13:02 Dyrcona mmorgan: Yes. I know that's where we lost our custom version. I just found a copy of it in a directory of mostly undifferentiated SQL scripts.
13:03 Dyrcona I signed off the patch, after all. :)
13:03 * mmorgan nods
13:04 Dyrcona OK, so what to do? Hack our changes into the production database, or drop the customization and fix our records with URIs to conform to what Evergreen expects?
13:42 Dyrcona customization--
13:43 Dyrcona DB function customization is particularly hard to track if you don't modify the base schema files, and even then you're likely to forget that you customized function X if the new code merges without conflicts.
13:44 Dyrcona I just recommended to staff here that we restore the customization for now but plan to get rid of it before our next upgrade.
14:26 Dyrcona Start one project, end up with 4.
14:44 mmorgan Dyrcona: It's been that kind of week, er, month. Or maybe year...
14:57 Dyrcona Yeahp...
15:22 Dyrcona DB server is slow while it's creating a database with another as a template.
15:29 dbriem joined #evergreen
15:43 collum joined #evergreen
16:35 * Dyrcona tests if setting an internal flag during a transaction, doing an update, then resetting the flag before commit works. I think it does, but the answer is that may depend on deferred triggers or not.
16:36 Dyrcona I know that the internal flag update won't be visible outside of the transaction.
16:36 Dyrcona Hmm... what's the thing to make all triggers immediate.....
16:40 Dyrcona SET CONSTRAINTS ALL IMMEDIATE; # If you ever need it.
16:40 Dyrcona That might break things for me but we'll see.
16:41 * Dyrcona has a feeling the test transaction won't finish in the next 20 minutes, so we'll have to wait until tomorrow morning.
16:51 jvwoolf left #evergreen
17:05 mmorgan left #evergreen
19:56 jihpringle joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat