Merge Record Assets Can Fail Because of Duplicate Copy Part Map Entries
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
New
|
Undecided
|
Unassigned |
Bug Description
Evergreen 2.12.8
OpenSRF 2.5.2
PostgreSQL 9.5.11
O/S Ubuntu 16.04.4
When merging records with parts it is possible for the asset.merge_
Looking in the postgres logs or running the function by hand gives something like the following:
psql:20180306_
DETAIL: Key (target_copy, part)=(16725391, 567427) already exists.
CONTEXT: SQL statement "UPDATE asset.copy_part_map
SET part = target_part.id
WHERE part = source_part.id"
PL/pgSQL function asset.merge_
I don't think this should be too hard to prevent, so I'll give it a go and post a branch soonish.
Changed in evergreen: | |
assignee: | Jason Stephenson (jstephenson) → nobody |
It appears that a very specific set of data lead to this occurring:
1. We have a copy on bib A with multiple parts.
2. It has a part on bib A and at least one part on bib B.
3. The labels of the parts in 2 are identical.
4. Bib A and bib B are merged, the order is not important.
For the sake of this discussion, we will assume that bib B is merged into bib A, i.e. that bib A is the one being kept.
The above triggers code in asset.record_ merge_assets that will update the asset.copy_part_map on the copy to set the part id for the part from bib B to the part id of the part with the matching label on bib A. Since the copy_part_map already has an entry for that part id on this copy, the duplicate key value error in the description is triggered and the record merge halts.
Our cataloger was able to get around this situation by performing the following steps:
1. delete the part on bib A
2. transfer the copy back to bib B
2. delete the part on bib B
4. transfer the copy back to bib A
Cumbersome, to say the least.
She also mentioned that it appears this occurred because the copy had been previously transferred from bib B to bib A, and that there appear to be duplicate entries on bib A, even though one of them is still on bib B. So, this is likely a duplicate of 1411422.
Whatever the case, there is definitely a bug here. Either a copy should not have parts on two different bibs, or the asset.record_ merge_assets function should be modified to handle that situation.