IRC log for #evergreen, 2022-07-13

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