| Time |
Nick |
Message |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:23 |
|
rjackson_isl_hom joined #evergreen |
| 07:54 |
|
agoben joined #evergreen |
| 07:58 |
|
Dyrcona joined #evergreen |
| 08:03 |
|
rfrasur joined #evergreen |
| 08:13 |
|
mantis1 joined #evergreen |
| 08:16 |
|
alynn26 joined #evergreen |
| 08:22 |
Dyrcona |
Whee! Fifteen hours to actually delete 35,279 bibs! |
| 08:23 |
Dyrcona |
I think I should try this with Pg12, but later..... |
| 08:29 |
Dyrcona |
psql:11_remove_workstations.sql:31: ERROR: Key (action.usr_circ_history=1132450) does not exist in asset.copy |
| 08:29 |
Dyrcona |
Make sense out of that one! :) |
| 08:30 |
csharp |
referring to a copy that was deleted from the DB? |
| 08:31 |
Dyrcona |
PL/pgSQL function action.maintain_usr_circ_history() line 55 at SQL statement |
| 08:32 |
Dyrcona |
There's some code between those two lines and there's no copy mentioned at all. |
| 08:33 |
Dyrcona |
That error literally says it's looking for a usr_circ_history id in asset.copy. |
| 08:34 |
csharp |
oh -hmm |
| 08:35 |
Dyrcona |
I'll bet the error is really coming from: action_usr_circ_history_target_copy_trig AFTER INSERT OR UPDATE ON action.usr_circ_history FOR EACH ROW EXECUTE PROCEDURE fake_fkey_tgr('target_copy') |
| 08:35 |
Dyrcona |
It is mentioned a bit lower in the output.... |
| 08:35 |
Dyrcona |
I missed it when scrolling up. |
| 08:38 |
Dyrcona |
Yeah, that trigger tries to use the current row id as the target copy, and if it doesn't exist in asset.copy it raises an exception. |
| 08:39 |
csharp |
huh |
| 08:40 |
Dyrcona |
EXECUTE 'SELECT ($1).' || quote_ident(TG_ARGV[0]) INTO copy_id USING NEW; |
| 08:41 |
csharp |
looking at the same thing |
| 08:41 |
Dyrcona |
I believe that's getting the current row id into copy_id, which is what the error says. |
| 08:42 |
Dyrcona |
Well, the NEW row id from the update/insert POV. |
| 08:42 |
Dyrcona |
Then below, it checks if that exists in asset.copy as an id, and if it doesn't, boom! |
| 08:43 |
Dyrcona |
I'll disable that trigger during the delete and see what happens. There's a potential that this will blow up later, after the deletes are done. |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:43 |
csharp |
seems like it should be using target_copy though, right? |
| 08:44 |
Dyrcona |
Well, it's a "fake" fkey, so I think we're assuming the target_copy was deleted or something like that. I don't know who wrote the function, so I don't know the rationale. |
| 08:45 |
* csharp |
blows the dust off git blame |
| 08:47 |
csharp |
6c13880e172 |
| 08:47 |
pinesol |
csharp: [evergreen|miker] Reorder some functions to avoid creation failure on an empty db; remove unused (and installation-killing) tsvector aggregate - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6c13880> |
| 08:47 |
csharp |
from the SVN days |
| 08:47 |
csharp |
that may not be where it was authored though |
| 08:50 |
Dyrcona |
It's coming from an update on action.circulation, so I'll just disable the trigger and see what happens. |
| 08:55 |
Dyrcona |
That works for now I just wonder if there will be problems later. I suppose that I could try updating some of the affected rows, later. They're easy enough to find with NULL checkin_lib and checkin_workstation. |
| 09:07 |
* miker |
reads up |
| 09:07 |
Dyrcona |
That trigger strikes again in 15_remove_ou_extras.sql. |
| 09:09 |
miker |
Dyrcona: are you wondering what those "fake_fkey" triggers are for? |
| 09:10 |
Dyrcona |
Well, partly that, and partly why it seems to be looking for a usr_circy_history id in asset.copy. |
| 09:10 |
Dyrcona |
I have assumptions, but they are probably incorrect. |
| 09:14 |
|
collum joined #evergreen |
| 09:16 |
miker |
the reason the trigger exists is that PG doesn't allow foreign keys to point at parent tables, like asset.copy is to serial.unit. fkeys must point at a unique column (or set of columns), which is implemented in PG using an index, but you can't have a unique index across tables, including in a parent-child hierarchy. and there are more Reasons(tm)... anyway, the best solution is a trigger that does the same thing that you'd want a native fkey to do. |
| 09:16 |
miker |
it works fine for all the cases we care about. |
| 09:16 |
* miker |
looks at the trigger def on that table specifically... |
| 09:18 |
Dyrcona |
So, in this case, it's likely the wrong function to use. |
| 09:18 |
miker |
Dyrcona: at least in the db I'm looking at, it's looking for a copy using the the target_copy column: action_usr_circ_history_target_copy_trig AFTER INSERT OR UPDATE ON action.usr_circ_history FOR EACH ROW EXECUTE PROCEDURE fake_fkey_tgr('target_copy') |
| 09:18 |
miker |
no, the param to the function in the trigger definition tells it which column to look at in the NEW row |
| 09:19 |
Dyrcona |
Turns our my error is actually coming from maintain_usr_circ_history_tgr on action.circulation. |
| 09:19 |
Dyrcona |
s/our/out/ |
| 09:19 |
miker |
that's exactly what the EXECUTE you pasted above does. it constructs a select that pulls the column named in TG_ARV[0] ('target_copy' here) out of NEW |
| 09:20 |
Dyrcona |
Ah, I see. |
| 09:25 |
miker |
Dyrcona: it /looks/ like maybe copies were real-deleted while that trigger was disabled (or before it existed), and now when your script goes to adjust circ history by issuing an UPDATE (line 55 of maintain-history trigger func) it |
| 09:25 |
miker |
's running into the fake fkey trigger |
| 09:26 |
Dyrcona |
Ok, so my *real* problem isn't the triggers. It's that I now have 2,212 rows in action.usr_circ_history on copies that are physically gone from the database, and 06_remove_copies.sql should delete from action.usr_circ_history. |
| 09:27 |
Dyrcona |
So, yeah, what miker said. :) |
| 09:33 |
miker |
Dyrcona: I think deleting is it, yeah. there's room for improvement in the trigger (or trigger def on some tables) to let copy fields be nullable... but because circs are involved and demand copies I think you'd still hit this in the end |
| 09:33 |
Dyrcona |
So, I'll have some users losing circ history....Fun with consortia where they actually share materials.... |
| 09:33 |
miker |
well, that's the argument for not real-deleting anything :) |
| 09:33 |
Dyrcona |
Right. It's one of many. |
| 09:34 |
miker |
yes, not THE, that's def true :) |
| 09:34 |
Dyrcona |
There are ways around it, but it explodes the database and makes a mockery of relational integrity. |
| 09:36 |
miker |
"imagine a choose your own adventure book where 10% of the 'if X, go to ...' instructions point you to page eleventy-purple-queue" |
| 09:39 |
Dyrcona |
:) |
| 09:46 |
Dyrcona |
I suppose it is a bad idea to run these scripts while Evergreen is actually hitting the database with all of the dropped triggers. |
| 09:52 |
Dyrcona |
So, you're able to delete from asset.copy while the deleted copy is referenced in action.usr_circ_history because there's no relation between the two tables, at least not in my 3.2 database. |
| 09:53 |
|
jvwoolf joined #evergreen |
| 09:53 |
Dyrcona |
You only get into trouble when you mess with the linked circulations for the deleted copies, and at the point this happens, I think the circulations should be gone already, so maybe there's a second bug in the remove ou data scripts? |
| 09:57 |
pinesol |
[evergreen|Bill Erickson] LP1882591 Empty combobox avoids default selection - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=435ff7a> |
| 09:58 |
Dyrcona |
Yeahp. I have 17,099 circulations on physically deleted copies. |
| 10:00 |
Dyrcona |
And 5 aged_circulations. |
| 10:01 |
Dyrcona |
Think I'll dump those to CSVs so I can compare to a db without the records deleted to see why they don't get removed. |
| 10:15 |
pinesol |
[evergreen|Jane Sandberg] LP1795469: Opac holdings sort now considers CN suffix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2c09f82> |
| 10:17 |
Dyrcona |
Well, I am able to delete the org_units when it is all done. |
| 10:22 |
|
jvwoolf1 joined #evergreen |
| 10:26 |
Dyrcona |
Yeahp. Looks like circulations, aged_circulations, and usr_circ_history need to be deleted for copies owned by the libraries being deleted. We have a lot of transit checkouts. |
| 10:26 |
JBoyer |
Dyrcona, one thing I've seen done recently is to create a new pre-cat item with a title like |
| 10:26 |
Dyrcona |
I think that should go in 04_remove_circ.sql. |
| 10:27 |
JBoyer |
"(MIssing Org) Item", then assigning it to all of the circs with bad item ids. Not any more true than they are now, but there's less screaming when they're touched. |
| 10:27 |
Dyrcona |
Hmm. That's a thought. |
| 10:28 |
rhamby |
Drycona: I'll be pushing some patches later today to address when a circ or hold links to a missing copy, volume or bib |
| 10:28 |
JBoyer |
It at least stops the spread of "Well, time to delete all of this..." |
| 10:28 |
rhamby |
in the removal script |
| 10:28 |
rhamby |
I'll look at usr_circ_history and aged_circulations too |
| 10:28 |
Dyrcona |
JBoyer: The point is to delete stuff, though. |
| 10:29 |
Dyrcona |
rhamby: Cool. I have a branch on github with a couple of additional changes. I've not made a pull request, yet. |
| 10:29 |
|
jvwoolf joined #evergreen |
| 10:29 |
rhamby |
Dyrcona: ok, I'm going to look at these and add in aged_hold_request too |
| 10:29 |
JBoyer |
To an extent, yeah. Depends on how far away you want to travel from what's actually deleted. :) Because if you wipe out those circs you're not altering annual circ stats and libraries get real grumpy about that. |
| 10:29 |
JBoyer |
s/not/now |
| 10:30 |
rhamby |
I'm seeing this happen on patrons that are being kept linking to other stuff so my method will basically be to link to precats / -1 entries |
| 10:31 |
Dyrcona |
JBoyer: Yes, which is why we should have a stats archive with the actual numbers. |
| 10:32 |
JBoyer |
Fair. |
| 10:32 |
rhamby |
I'm fine with the stats arcive if nothing else to avoid "why did this number change" spiraling labyrinths of madness discussions |
| 10:32 |
rhamby |
but I may have feelings there |
| 10:33 |
Dyrcona |
I agree. It's tough to explain. We have a dashboard where we calculate stats at the end of the year and the libraries use those numbers. |
| 10:49 |
pinesol |
[evergreen|Mike Risher] lp1776757 Default Billing Price Not Updating - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=79224bb> |
| 10:49 |
pinesol |
[evergreen|Galen Charlton] LP#1776757: (follow-up) keep input for amount as type "number" - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ade09f8> |
| 11:35 |
|
jihpringle joined #evergreen |
| 11:59 |
|
collum_ joined #evergreen |
| 12:32 |
|
mrisher joined #evergreen |
| 12:38 |
|
mrisher_ joined #evergreen |
| 12:38 |
|
collum joined #evergreen |
| 12:57 |
|
collum_ joined #evergreen |
| 13:34 |
|
collum joined #evergreen |
| 13:37 |
|
mrisher joined #evergreen |
| 13:49 |
|
jvwoolf joined #evergreen |
| 13:58 |
rhamby |
Drycona just so you know if you do a pull on the migration-tools later I'm pushing the vacuum stuff to 20 and a new 19 will be some consortium cleanup stuff |
| 14:13 |
Dyrcona |
rhamby: OK. Good to know. I'll look out for it later. I was also thinking that the 00 could do some more setup. As it is, I skip it, 'cause we have the default admin user. |
| 14:13 |
rhamby |
that's fair, it probably could use some enrichment |
| 14:14 |
rhamby |
I'll push this soon but doing a bunch of updates to aged_circulation/hold_request to not lose stats for cross consortium checkouts |
| 14:17 |
rhamby |
and done |
| 14:19 |
Dyrcona |
Cool. I'll give the new versions a try later this week. I may try switching my main DB instance from Pg 9.6 to Pg 12 beforehand. |
| 14:20 |
berick |
4355cc6 |
| 14:20 |
pinesol |
berick: [evergreen|Jason Etheridge] LP1819542 Hanging transits can cause checkins to fail - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4355cc6> |
| 14:21 |
berick |
eyeballing the above, something caught my attention |
| 14:21 |
berick |
+ $self->transit(undef); |
| 14:21 |
berick |
pretty sure that won't do anything |
| 14:22 |
berick |
$self->{transit} = undef # likely required |
| 14:27 |
Dyrcona |
berick: Yeahp, but I think $self->clear_transit(); would be a better choice. |
| 14:28 |
berick |
Dyrcona: autoload in thise case instead of fieldmapper |
| 14:28 |
Dyrcona |
Assuming it is a Fieldmapper object, which I haven't verified. |
| 14:28 |
Dyrcona |
Ah, OK, then. |
| 14:29 |
Dyrcona |
I should have realized with the hashref, actually. |
| 14:29 |
Dyrcona |
@blame Beginning of a head ache |
| 14:29 |
pinesol |
Dyrcona: Beginning of a head ache is NOT CONNECTED TO THE NETWORK!!! |
| 14:29 |
Dyrcona |
berick++ |
| 14:29 |
Dyrcona |
rhamby++ |
| 14:30 |
Dyrcona |
My brain is NOT CONNECTED TO THE NETWORK!!! |
| 14:30 |
Dyrcona |
:) |
| 14:31 |
Dyrcona |
Oh, yeah. I was gonna do something..... |
| 14:38 |
|
collum joined #evergreen |
| 14:45 |
jihpringle |
berick: looking at https://bugs.launchpad.net/evergreen/+bug/1869898 is there a best way to indicate bugs we'd consider blockers for moving to the angular catalogue as default? ie webstaffblocker tag or something else? |
| 14:45 |
pinesol |
Launchpad bug 1869898 in Evergreen "Make Angular Staff Catalog the default for staff for EG-next (3.6)" [Wishlist,New] |
| 14:46 |
berick |
jihpringle: no, i don't think we have a tag for that. probably good to have, though |
| 14:49 |
jihpringle |
is there discussion that needs to happen or do we just start using something like angularcatblocker? |
| 14:50 |
jihpringle |
I've run into two so far that we'd consider blockers (but I can just keep my own list for now if we're not ready for this yet :) ) |
| 14:50 |
jeff |
would "releaseblocker" be appropriate? |
| 14:51 |
berick |
jeff: i think that implies the release would be delayed |
| 14:52 |
JBoyer |
featureblocker would be the most generic, but so generic it's not much good. :) |
| 14:53 |
JBoyer |
Unless a bug is only targeting a single milestone, perhaps. |
| 14:53 |
alynn26 |
I say go for angularcatblocker. Because that is what we are wanting to block. |
| 14:54 |
jeff |
berick: ah, i was overlooking the fact that bug 1869898 itself might not be considered as blocking the release of 3.6. |
| 14:54 |
pinesol |
Launchpad bug 1869898 in Evergreen "Make Angular Staff Catalog the default for staff for EG-next (3.6)" [Wishlist,New] https://launchpad.net/bugs/1869898 |
| 14:55 |
jeff |
JBoyer: yeah, featureblocker seemed to lack specificity that could be implied with releaseblocker as "the upcoming/next release" :-) |
| 14:58 |
gmcharlt |
yeah, let's not use releaseblocker |
| 14:58 |
gmcharlt |
angularcatblocker works for me |
| 15:00 |
jeff |
+1 |
| 15:05 |
jeff |
bah. hold policy lacks user age as an input. |
| 15:07 |
gmcharlt |
Angular Cat Blocker: https://dribbble.com/shots/3897208-Low-poly-dog |
| 15:07 |
berick |
:) |
| 15:07 |
jihpringle |
:) |
| 15:08 |
alynn26 |
lol |
| 15:10 |
Dyrcona |
gmcharlt++ |
| 15:16 |
berick |
bah, just noticed i forgot to port the 3.5 sql upgrade script to rel_3_5. it's in master, though |
| 15:16 |
* berick |
fixes |
| 15:27 |
Dyrcona |
Looking into upgrading to Pg 12 from 9.6 and there have been changes for standby configuration, notably in the removal of recovery.conf. |
| 15:41 |
csharp |
Dyrcona: hmm interesting. I'll have to take a look |
| 15:44 |
|
nfBurton joined #evergreen |
| 15:45 |
Dyrcona |
csharp: https://www.postgresql.org/docs/current/release-12.html |
| 15:45 |
Dyrcona |
Might save you some time searching. |
| 15:45 |
csharp |
Dyrcona++ #thanks |
| 15:46 |
Dyrcona |
I'm considering skipping 10 and 11 and going straight to 12 from 9.6 if testing pans out. |
| 15:53 |
gmcharlt |
csharp: if you have an eye for looking at the hopeless holds branch again (https://bugs.launchpad.net/evergreen/+bug/1811710), I've rebased it and very likely figured out the cause of the errors you were seeing back in January |
| 15:53 |
pinesol |
Launchpad bug 1811710 in Evergreen "wishlist: Improvements to Hopeless Holds" [Wishlist,Confirmed] |
| 15:54 |
csharp |
gmcharlt: thanks - will put it on The List |
| 16:11 |
gmcharlt |
berick: noting that the hopeless holds branch includes an alternate version of part of the labeling fix in bug 1889133 |
| 16:11 |
pinesol |
Launchpad bug 1889133 in Evergreen "Angular Staff Catalog: Hold Status Blank" [Undecided,Confirmed] https://launchpad.net/bugs/1889133 |
| 16:12 |
gmcharlt |
haven't looked into whether there's reason to prefer one over the other, but either way, just wanted to mention the upcoming merge conflict ahead of time |
| 16:53 |
berick |
gmcharlt: thanks for the heads up. no preference on general implementation. 2 parts of my branch i like FWIW are "Status" => "Hold Status" relabel and sort support (albeit on the numeric code) of the hold status column. |
| 17:29 |
|
mmorgan left #evergreen |
| 18:00 |
|
jihpringle joined #evergreen |
| 18:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:34 |
|
abowling1 joined #evergreen |
| 18:44 |
|
mrisher_ joined #evergreen |
| 18:44 |
|
abowling joined #evergreen |
| 19:21 |
pinesol |
[evergreen|Bill Erickson] LP1889296 Staffcat holds request time includes time - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7570d7e> |
| 20:50 |
|
sandbergja joined #evergreen |
| 20:56 |
|
sandbergja joined #evergreen |
| 20:59 |
|
sandbergja joined #evergreen |
| 21:01 |
|
bshum joined #evergreen |
| 21:33 |
|
sandbergja joined #evergreen |
