| Time |
Nick |
Message |
| 00:04 |
|
dbwells joined #evergreen |
| 00:08 |
|
dbwells joined #evergreen |
| 02:46 |
|
dbwells joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl_hom joined #evergreen |
| 07:41 |
|
dbwells joined #evergreen |
| 08:02 |
|
Dyrcona joined #evergreen |
| 08:23 |
|
mantis1 joined #evergreen |
| 08:26 |
|
alynn26 joined #evergreen |
| 08:29 |
|
sandbergja joined #evergreen |
| 08:32 |
|
rfrasur joined #evergreen |
| 08:34 |
|
mmorgan joined #evergreen |
| 09:32 |
|
dbwells joined #evergreen |
| 10:06 |
|
jonadab joined #evergreen |
| 10:20 |
|
sandbergja joined #evergreen |
| 10:55 |
pinesol |
[evergreen|Bill Erickson] LP1855737 Don't send error object across shared worker port - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d5d7985> |
| 12:10 |
|
jihpringle joined #evergreen |
| 12:15 |
sandbergja |
Is there a way to verify that a particular ORDERS acq.edi_message was created using the new edi_order_pusher? Is an empty jedi column a good way to tell? |
| 12:17 |
csharp |
hmm |
| 12:19 |
csharp |
sandbergja: that sounds right to me, looking at both pusher scripts |
| 12:19 |
Dyrcona |
I've got rows with status = complete jedi = empty and edi = <content>, so what csharp said. :) |
| 12:20 |
csharp |
the original pusher puts data in the jedi column and the new one doesn't |
| 12:21 |
sandbergja |
Excellent! Thanks! |
| 12:21 |
csharp |
same here - and the earliest one is right around the time we transitioned to non-JEDI ordering |
| 12:21 |
csharp |
sandbergja: you also know about --test-mode on the new pusher, right? |
| 12:22 |
sandbergja |
yes! that was super helpful |
| 12:22 |
csharp |
good |
| 12:22 |
sandbergja |
Oh man, I think we are all switched over to the new EDI system! |
| 12:23 |
csharp |
sandbergja++ |
| 12:23 |
csharp |
blessed relief |
| 12:23 |
sandbergja |
berick++ |
| 12:23 |
sandbergja |
csharp++ |
| 12:23 |
csharp |
berick++ |
| 12:23 |
sandbergja |
Dyrcona++ |
| 12:26 |
Dyrcona |
We did some time ago, but gradually. You can actually move some libraries over and leave others on the old pusher for a while. |
| 12:27 |
Dyrcona |
berick++ |
| 12:29 |
|
mantis1 joined #evergreen |
| 12:36 |
|
mantis1 joined #evergreen |
| 12:37 |
|
mantis1 joined #evergreen |
| 12:40 |
|
mantis1 joined #evergreen |
| 12:42 |
|
mantis1 joined #evergreen |
| 12:49 |
|
mantis1 joined #evergreen |
| 13:24 |
|
gmcharlt joined #evergreen |
| 13:26 |
|
dbs joined #evergreen |
| 13:26 |
|
Christineb joined #evergreen |
| 13:42 |
Dyrcona |
Whee: SELECT * FROM actor.org_unit_closed WHERE '1798-01-09T23:59:00-04:00' between close_start and close_end AND org_unit = '8' ORDER BY close_start ASC, close_end DESC LIMIT 1 |
| 13:43 |
Dyrcona |
And now 1404.... |
| 14:08 |
csharp |
maybe some history buff is retroactively putting in closed dates for previous centuries? :-) |
| 14:08 |
csharp |
"Closed reason: Salem Witch Trials" |
| 14:11 |
Dyrcona |
heh. |
| 14:11 |
Dyrcona |
Maybe in NOBLE, but not here. :) |
| 14:11 |
csharp |
:-) |
| 14:12 |
Dyrcona |
I was just messing with the data from bug 1901191 |
| 14:12 |
pinesol |
Launchpad bug 1901191 in Evergreen "open-ils.storage.actor.org_unit.closed_date.overlap can hang and gives inconsistent results" [Undecided,New] https://launchpad.net/bugs/1901191 |
| 14:13 |
Dyrcona |
I noticed that there are no dates for 2016 or 2017, so I deleted everything before 2018 to see if that made a difference. It doesn't. |
| 14:14 |
Dyrcona |
Deleting the entry for 2020-10-11 does make a difference. |
| 14:14 |
Dyrcona |
Making a multi-day entry out of 2020-10-11 and 2020-10-12 still causes the function to hang. |
| 14:15 |
Dyrcona |
Probably because when 2020-10-11 is deleted, it becomes the start date in the range. |
| 14:21 |
mmorgan |
Dyrcona: csharp: In case you were planning a trip to Salem this year, don't: https://www.thrillist.com/news/nation/salem-massachusetts-closed-halloween-2020 |
| 14:22 |
Dyrcona |
mmorgan: I know, and I was in Salem on Wednesday. |
| 14:22 |
mmorgan |
Folks are still coming in droves :-/ |
| 14:23 |
Dyrcona |
I'm not surprised. I took a relative to Salem for a medical test. |
| 14:25 |
Dyrcona |
"October has been canceled." |
| 14:28 |
* mmorgan |
made the mistake of driving through on Saturday, rather, crawling through... |
| 14:29 |
Dyrcona |
Heh. |
| 14:35 |
Dyrcona |
My! How the hack-away agenda has grown! |
| 14:41 |
jeffdavis |
hm, 1474 calls to open-ils.actor.settings.apply.user_or_ws for the same authtoken over a 3 minute period, including 156 calls in 5 seconds at one point, how does that happen? |
| 14:43 |
Dyrcona |
jeffdavis: Sounds similar to bug 1848550 |
| 14:43 |
pinesol |
Launchpad bug 1848550 in Evergreen "Cache settings more aggressively in web client" [Undecided,Fix released] https://launchpad.net/bugs/1848550 |
| 14:43 |
Dyrcona |
I know it's not the same thing, exactly. |
| 14:44 |
berick |
jeffdavis: setting a value in a loop |
| 14:45 |
berick |
which wasn't a problem so much before settings moved from the client to the server |
| 14:45 |
berick |
but yes we also need to indexeddb-cache those settings as well. they're just process cache now |
| 14:45 |
Dyrcona |
Loops... We're having fun with loop-de-loops! |
| 14:46 |
Dyrcona |
Oops. Got past the Battle of Hastings. Guess I'd better terminate the storage drone. :) |
| 14:47 |
berick |
heh |
| 14:52 |
jeffdavis |
looks like those excessive requests may be happening during checkin |
| 14:55 |
jeffdavis |
hard to tell though because the logs just show a hashref like HASH(0x4fdaff8), not the actual setting values |
| 15:06 |
jeffdavis |
looks like compile_checkin_args will update circ.checkin.strict_barcode and circ.checkin.do_inventory_update on each checkin, even when unchanged |
| 15:06 |
jeffdavis |
in Open-ILS/web/js/ui/default/staff/circ/checkin/app.js |
| 15:25 |
jeffdavis |
I guess this is a bit different from 1848550 - the issue isn't with excessive setting lookups but with applying setting updates even when the settings are actually unchanged |
| 15:26 |
jeffdavis |
Knowing when a user/ws setting has changed seems trickier since they're more likely to be modified mid-session - we can't just refresh the client-side cache on login like we do for rarely-changing org settings. |
| 15:27 |
berick |
jeffdavis: the workstation settings code keeps a process-local cache of all the values it's loaded / applied. it could compare values pased to setItem to it's already cached value |
| 15:27 |
berick |
and skip the lookup when new === old |
| 15:28 |
pinesol |
[evergreen|Bill Erickson] LP1901038 Repair Angular catalog journal title search - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9b89185> |
| 15:28 |
berick |
s/lookup/setting/ |
| 15:30 |
jeffdavis |
oh awesome, yeah that's a much easier fix |
| 15:32 |
|
mantis1 left #evergreen |
| 16:04 |
jeffdavis |
bug 1901247 |
| 16:04 |
pinesol |
Launchpad bug 1901247 in Evergreen "Skip user/workstation setting updates when the value is unchanged" [Undecided,New] https://launchpad.net/bugs/1901247 |
| 16:04 |
berick |
jeffdavis++ |
| 16:39 |
JBoyer |
csharp you around? |
| 16:43 |
JBoyer |
ah, well. Good weekend all! |
| 16:45 |
|
phasefx_ joined #evergreen |
| 16:47 |
|
pinesol` joined #evergreen |
| 16:50 |
|
dbs joined #evergreen |
| 16:50 |
|
yar joined #evergreen |
| 16:50 |
|
yeats joined #evergreen |
| 16:50 |
|
berick joined #evergreen |
| 16:55 |
|
csharp joined #evergreen |
| 16:58 |
|
jvwoolf1 left #evergreen |
| 16:59 |
|
berick joined #evergreen |
| 17:09 |
|
csharp joined #evergreen |
| 17:17 |
|
mmorgan left #evergreen |
| 17:39 |
|
yboston joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 21:51 |
|
sandbergja joined #evergreen |
| 23:25 |
|
dluch joined #evergreen |
| 23:25 |
|
Bmagic joined #evergreen |
| 23:25 |
|
devted joined #evergreen |
