| Time |
Nick |
Message |
| 00:25 |
|
kworstell_isl joined #evergreen |
| 06:10 |
|
JBoyer joined #evergreen |
| 07:03 |
|
Christineb joined #evergreen |
| 07:11 |
|
JBoyer joined #evergreen |
| 08:02 |
|
BDorsey joined #evergreen |
| 08:03 |
|
collum joined #evergreen |
| 08:18 |
|
rfrasur joined #evergreen |
| 08:24 |
|
mantis1 joined #evergreen |
| 08:39 |
|
Dyrcona joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 09:00 |
|
kworstell-isl joined #evergreen |
| 09:24 |
|
collum joined #evergreen |
| 09:35 |
|
dguarrac joined #evergreen |
| 11:32 |
|
jvwoolf joined #evergreen |
| 11:47 |
|
mantis1 joined #evergreen |
| 12:05 |
|
jihpringle joined #evergreen |
| 12:37 |
jvwoolf |
I added a new entry to config.biblio_fingerprint and then ran a paralell reingest. It still seems like the addtion to the fingerprint is only being picked up for new bib records. Am I missing something? |
| 12:38 |
jvwoolf |
I did run the pingest.pl with --skip-browse |
| 12:39 |
Dyrcona |
I don't think pingest.pl regenerates fingerprints. It doesn't update bib records. It uses the database functions to create the search indexes. |
| 12:40 |
JBoyer |
jvwoolf, fingerprints are only generated when biblio.record_entry gets an insert or update, so there's not a great tool to use for that other than sql. |
| 12:40 |
jvwoolf |
Well, that explains that :) |
| 12:42 |
Dyrcona |
Generating fingerprints could probably be added as a feature. |
| 12:43 |
jvwoolf |
JBoyer: So if I updated the edit_dates in a batch that might do it? |
| 12:43 |
jvwoolf |
Dyrcona++ I can create that wishlist ticket if it's not there |
| 12:44 |
JBoyer |
jvwoolf, yes, though that one would make me nervous. (that is actual data, after all.) The trigger doesn't bother to actually verify anything other than the deleted flag, so you may just be able to do an update that sets id = id and it'll be good to go. |
| 12:44 |
JBoyer |
Hah, I suppose you could also set fingerprint = 'fixme!' :D |
| 12:45 |
Dyrcona |
:) |
| 12:46 |
|
mantis1 joined #evergreen |
| 12:49 |
jvwoolf |
JBoyer++ |
| 12:50 |
jvwoolf |
I got a test database and a batch of records to target, I've got nothing to lose! |
| 12:50 |
Dyrcona |
jvwoolf++ |
| 12:51 |
JBoyer |
jvwoolf++ |
| 13:07 |
pinesol |
News from commits: Docs: Evergreen web services docs <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2ca151971be655225c12c34fef3191fcdcd8ac38> |
| 13:11 |
|
JBoyer joined #evergreen |
| 13:20 |
|
JBoyer joined #evergreen |
| 13:57 |
jvwoolf |
JBoyer: Setting the fingerprints to "fixme" worked! |
| 13:58 |
JBoyer |
:D |
| 13:58 |
jvwoolf |
My next question is how do I get the metarecords to regenerate? |
| 14:01 |
JBoyer |
Ah, well, now you're back to pingest.pl. metabib.remap_metarecord_for_bib is called in the biblio.indexing_ingest_or_delete trigger func |
| 14:21 |
jvwoolf |
JBoyer: Ah, that's probably how I got pingest.pl in my head to begin with. Thanks! |
| 14:21 |
jvwoolf |
JBoyer++ |
| 15:04 |
|
jihpringle joined #evergreen |
| 15:13 |
Dyrcona |
csharp_: Do you know if the pcrud calls mentioned in Lp 2002693 are hitting the server? This sounds like behavior described before where there is drone exhaustion. |
| 15:13 |
pinesol |
Launchpad bug 2002693 in Evergreen "Logging out on a page with a pcrud call floods browser with errors" [High,New] https://launchpad.net/bugs/2002693 |
| 16:56 |
Bmagic |
This is strange: how is it possible for me to have two rows in asset.copy with the same ID number! Both are undeleted. the id column is the primary key. I realize that serial.unit is an inherited table, but I didn't think that when you select on asset.copy, it could include serial.unit rows? |
| 16:58 |
berick |
so that's why all the flights were grounded yesterday |
| 16:58 |
Bmagic |
lol |
| 17:00 |
Bmagic |
the clue is that the ID's that are duplicate in asset.copy are exactly the same ID's that appear in serial.unit |
| 17:03 |
Bmagic |
is there a trigger that I'm not seeing that creates a row in asset.copy when a row is inserted into serial.unit? |
| 17:08 |
* mmorgan |
has never seen two rows with the same asset.copy id - unless a join is involved. |
| 17:08 |
mmorgan |
That would scare me! |
| 17:09 |
Bmagic |
for this particular database, I have this command: SET CONSTRAINTS ALL DEFERRED.. which I thought, would get resolved after commit; |
| 17:09 |
Bmagic |
but maybe not? |
| 17:14 |
|
mmorgan left #evergreen |
| 17:17 |
Bmagic |
ok, I think I've confirmed that when you seelct rows from asset.copy, it includes rows from serial.unit. I've temporarily forgotten how PG inheritance works |
| 17:19 |
berick |
Bmagic: hmm, serial.unit uses the same id sequence as asset.copy. i would not expect dupes. |
| 17:19 |
berick |
nextval('asset.copy_id_seq'::regclass) |
| 17:19 |
Bmagic |
select count(su.id) from only asset.copy ac join serial.unit su on(su.id=ac.id) |
| 17:20 |
Bmagic |
vs. |
| 17:20 |
Bmagic |
select count(su.id) from asset.copy ac join serial.unit su on(su.id=ac.id) |
| 17:20 |
|
jvwoolf left #evergreen |
| 17:21 |
Bmagic |
this is how I ended up here. My generated dataset (for the enhanced concerto set FYI), included serial.unit rows when selecting rows out of asset.copy |
| 17:24 |
Bmagic |
I seem to have discovered a loophole here. I've generated the dataset, including the serial.unit rows assigned to asset.copy. And when I restore that data, Postgres has not problem putting those duplicate ID's into asset.copy. If you restore, generate, restore, asset.copy<->serial.unit rows end up mulitplying in asset.copy |
| 17:34 |
|
jihpringle joined #evergreen |
| 18:26 |
|
jihpringle joined #evergreen |
