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.
| Jason Stephenson (jstephenson) wrote | #1 |
| 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_
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_