IRC log for #evergreen, 2020-11-23

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

Time	Nick	Message
06:00	pinesol	News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
07:34		rjackson_isl_hom joined #evergreen
08:03		rfrasur joined #evergreen
08:07		mantis2 joined #evergreen
08:08		Dyrcona joined #evergreen
08:08	Dyrcona	Umm... Why are columns out of order in a table after a pg restore?
08:09	Dyrcona	Maybe I should ask in #postgresql?
08:11	Dyrcona	So, in a Pg 12 database restored from a 9.6 dump, the hold and cancel_time fields in action.hold_transit_copy are swapped compared to the order that they had in the source database.
08:12	Dyrcona	This makes testing my update script impossible.
08:13	Dyrcona	Grr... I'll have to ask in #postgresql. I can't have this happening.
08:18	csharp	I'm under the impression that column order is not static unless you ask for it in a select, but I haven't investigated that recently
08:19	Dyrcona	I suspect it has something to do with the inheritance on action.transit_copy, too.
08:19	csharp	https://stackoverflow.com/questions/34452414/does-column-order-matter-in-postgresql-tables - hmm - maybe my impression is wrong
08:20	Dyrcona	But, looking at \d action.hold_transit_copy on the two tables shows this: https://pastebin.com/10cNsNdV
08:21	Dyrcona	csharp: What you shared is not applicable to my situation.
08:21	csharp	yeah
08:24	Dyrcona	I've tossed a question about it in #postgresql.
08:24	Dyrcona	I'm going to restore the Pg 9.6 database on this server and see what happens.
08:30	Dyrcona	It happened on Pg 13, too. I'll check 10 and 11 while I'm at it.
08:30	Dyrcona	sql-mode++
08:32	Dyrcona	Oh! It'd different on my 9.6 database that was pg_restore'd.... So, it must be the inheritance. I suspect that cancel_time was added later.
08:35	Dyrcona	So table order doesn't matter, until it does. :)
08:35		mmorgan joined #evergreen
08:35	Dyrcona	I'll have to run this script live without testing it, or I could add a rollback just to check the syntax.
08:37	csharp	https://stackoverflow.com/a/285740/1692794 - I learned that you can see the order in pg_attribute.attnum but also learned that changing that is a pain
08:40	Dyrcona	csharp: That's interesting, but the order of the columns in the destination table hasn't changed, so I'll just select the columns in that order, and I should be good to go.
08:45	Dyrcona	I think I'm leaning toward joining the camp of "table inheritance considered harmful."
08:47	Dyrcona	"That's a bingo!"
08:55		mmorgan1 joined #evergreen
09:27		dbwells joined #evergreen
10:07		rlefaive joined #evergreen
11:18	Bmagic	when a hold is automatically force recalled via the library setting, does Evergreen create a row in action.hold_request for the force recall? Or does it handle it via some other method?
11:18	Bmagic	sorry, "when an item* is automatically"
11:19	Bmagic	library setting is "Circulation duration that triggers a recall"
11:21	Bmagic	looks like it has something to do with circ.recall.target.... so not a row in action.hold_request
11:26	mmorgan	Bmagic: circ.recall.target is an action_trigger hook
11:27	Bmagic	yep... crawling through the code. It appears that this code only starts executing when a hold is placed and there are no copies.. but some of the copies are still in circulation AND have been loaned greater than this library setting
11:28	Bmagic	if it finds a copy that has been circulated greater than the threshold, it will do all the things from the documentation: https://docs.evergreen-ils.org/eg/docs/latest/admin/hold_driven_recalls.html
11:29	Bmagic	If the patron doesn't get notified, then in theory, they could get an overdue notice (if that's setup) - and then they would be prompted to return it. I think I understand.
11:35	Dyrcona	Whee! Added curbside to production last night and hold notifications appear to be busted this morning.
11:41	Dyrcona	And, no error output in action_trigger.event_output for the error events!
11:46	Bmagic	Dyrcona: sorry to hear that
11:46	Dyrcona	Not as sorry as I am. :)
11:47	mmorgan	Dyrcona: Just the hold notifications are broken?
11:49	Dyrcona	Emails are broken, but I can fix it.
11:57	Dyrcona	Well, maybe the issue isn't what I thought it was.
11:59	Dyrcona	Event.pm:224:] Event reacting failed with Can't locate object method "handler" via package "SendEmail" (perhaps you forgot to load "SendEmail"?) at /usr/local/share/perl/5.22.1/OpenILS/Application/Trigger/ModRunner.pm line 161.
12:00	Dyrcona	Hmm.. Looks like the files are there.
12:01	jeff	perhaps check syntax via something like perl -c OpenILS/Application/Trigger/SendEmail.pm
12:01	Dyrcona	How come this didn't break on training?
12:01	Dyrcona	jeff: Thanks, I'll do that before doing anything else.
12:01	Dyrcona	(I would have gotten there eventually.)
12:01	jeff	I think a recent fix for the broken way we were trying to encode headers may have introduced a new dependency, but can't be sure without looking.
12:02	Dyrcona	Email::MIME is missing!
12:02	Dyrcona	jeff++
12:05		jihpringle joined #evergreen
12:10	Dyrcona	So, the upshot, never update your Evergreen installation, just be happy where you are. :)
12:21	csharp	Dyrcona++
12:50		mantis2 left #evergreen
12:52		mantis2 joined #evergreen
14:01		sandbergja joined #evergreen
14:27	Dyrcona	So, i have resolved most of it, but I have checkout receipt email events getting an error status with no error output, and I'm not finding anything in the syslogs, so far.
14:30	Dyrcona	No template_output nor async_output, either.
14:32	Dyrcona	No errors before today in the database.
14:34	Bmagic	Dyrcona++
14:35	Dyrcona	I'm updating the events to pending again to see what happens.
14:39	Dyrcona	IDK, some work, some don't.
14:51	Dyrcona	They seem to have all been processed by the same 4 backend process ids.
14:55	Dyrcona	Those processes are no longer running.
15:02	Dyrcona	No more syntax errors in the Trigger code.
15:03	Dyrcona	I had services shut off when I made the fix, too.
15:09	Dyrcona	Hm. These events must be getting processed elsewhere!
15:19	Dyrcona	Bizarre. It appears that the problem was on some of the brickheads.
15:20	Dyrcona	Yeahp. The two that are still on Xenial and didn't have prerequisites updated.
15:20	Dyrcona	I wonder if what I did fixed the issue.
15:24	Dyrcona	The downsides of running a "mixed" environment....
15:31		mantis2 left #evergreen
15:34	Dyrcona	It looks like I need to restart services, too. :(
15:58	Bmagic	Are there some tweaks that I can employ to make the local zips.txt file do something when the same zipcode is specified more than once?
16:02	Bmagic	Like "default" to one over the other? Or is it just "last one specified" takes precedence?
16:15	csharp	Bmagic: Open-ILS/src/perlmods/lib/OpenILS/Application/Search/Zips.pm appears to be about as simple as it can get
16:16	Bmagic	checking it out
16:16	csharp	not sure what it does with multiple matches though, might just be a question of what Perl does in that circumstance
16:16	Bmagic	oh man, you're right
16:17	Bmagic	well, that code seems to track with what we see - the LAST entry is the default
16:18	Bmagic	wait!
16:18	Bmagic	there is a column for default
16:19	Bmagic	it seems that if the user doesn't specify "1" for the default column, then the data is ignore completely?
16:59		JBoyer joined #evergreen
17:16		mmorgan left #evergreen
17:49		rjackson_isl_hom joined #evergreen
18:00	pinesol	News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
18:42		Cocopuff2018 joined #evergreen
19:04		sandbergja joined #evergreen