Merge Record Assets Can Fail Because of Duplicate Copy Part Map Entries

Bug #1753835 reported by Jason Stephenson on 2018-03-06
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
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_record_assets database function to attempt to insert duplicate entries in asset.copy_part_map, thus causing the record merge to fail with an unhelpful message to staff.

Looking in the postgres logs or running the function by hand gives something like the following:

psql:20180306_merge_record_assets.sql:4: ERROR: duplicate key value violates unique constraint "copy_part_map_cp_part_idx"
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_record_assets(bigint,bigint) line 210 at SQL statement

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 :

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.

Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers