metabib.remap_metarecord_for_bib has bad logic
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
The first thing done by metabib.
The second thing done is to loop over metarecord entries by joining to metarecord_
Both of these lines were introduced at the same time in 2010, so I am unsure what the logic is supposed to be. I highly suspect that something that is supposed to be happening is not, though, and that the bad logic is creating problems elsewhere, for example parallel hold targeting that joins to the source map table and can find no entries there. In that case holds are skipped over.
Changed in evergreen: | |
status: | New → Incomplete |
Changed in evergreen: | |
status: | Incomplete → Triaged |
tags: | added: metarecords |
Quick note.
I don't have time to tackle this ATM, but it looks like the initial DELETE needs to be moved down into the IF branch of the conditional inside the first LOOP.