Comment 1 for bug 1753835

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.