Evergreen

bibliographic record merge

Bug #1145213 reported by Tim Spindler
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned
Evergreen 3.0.2
2.12
Fix Released
Medium
Unassigned
Evergreen 2.12.8

Bug Description

Evergreen 2.3.3

We are finding that when merging bibliographic records that in some instances but not all instances it is deleting the volume field record. At the database level, I was able to determine this..

MARC Record 1 with 2 copies and two different call numbers for branch 1 is merged with MARC Record 2 with with a call number and a copy from branch 1. The asset.call_number table is updated with the correct bib id but the row for one of the call numbers gets updated with a deleted as true. This occurs on one of the call numbers not both. The deleted column on the copy record remains false. It happens inconsistently but may be if the value in the label column is equal to the label column in both but one of the rows has a different prefix. I need to test this further.

Revision history for this message
Ben Shum (bshum) wrote :

This sounds similar to what we recently fixed with bug 1074484 where deleted CNs were being used on bib merge. That said, I think it's slightly different if you're saying the prefixes are distinct, which makes me wonder if there's a larger issue where we need to check for prefix/suffix in relation to the labels when determining merge choices.

Changed in evergreen:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Rogan Hamby (rogan-hamby) wrote :

This isn't limited to prefixes and suffixes and is actually two separate issues, both of which are fixed by the patch at user/rogan/lp11452113_bib_merge

Testing I did ....

bib 250 - new lead
org 4 acn 'F Cline' copy 1

bib 251 - merged from target
org 5 acn 'F Cline' copy 2
org 6 acn 'JF Cline' copy 3
org 4 acn 'F Cline' copy 4

copy 2 ACN moved from 251 to 250 correctly
copy 3 ACN moved from 251 to 250 correctly
copy 4 moved from it's ACN to the ACN of copy 1 correctly
bib 251 deleted

acn of copy 2 not deleted (correct)
acn of copy 3 not deleted (correct)
acn of copy 4 note deleted (incorrect)

All of these had -1 for prefix and suffix.

Looking at the merge assets function it looks like the logic to move assets assumes that it will be able to move and never evaluates for deletion. I think the ticket report on this is incorrect because it never deletes the volume (which is still a bug).

However, it also does not pay attention to prefixes (which is a separate problem).

With the patch the volume correctly deletes. I also added a prefix to the org 4 bib 251 record, and post patch it no longer moved over to 251 since the prefix differs now (it was moved over incorrectly before).

Rogan Hamby (rogan-hamby)
tags: added: pullrequest
Revision history for this message
Rogan Hamby (rogan-hamby) wrote :

Having some local file corruption issues that affected my git that I didn't catch at first so pushing a revised version to make sure it's clean:

user/rogan/lp11452113_bib_merge_revised

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=blobdiff;f=Open-ILS/src/sql/Pg/999.functions.global.sql;h=512427c2a6f32913534ad04d8cfc408eb9362260;hp=612a4ba3c29e2268db52dc778edd80201ede4bd6;hb=ca2bd747070d0f8e367033ae4a09a7d5c2443693;hpb=db7b67abd0c52a1ae92f35a7b4f28f441a9af8ad

Revision history for this message
Cesar V (cesardv) wrote :

Sign-off branch and pgtab test for this at:

user/cesardv/lp1145213-bib_merge_func_merge_record_assets-signoff

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/cesardv/lp1145213-bib_merge_func_merge_record_assets-signoff

Cesar V (cesardv)
tags: added: signedoff
Andrea Neiman (aneiman)
Changed in evergreen:
milestone: none → 3.0.1
Evergreen Bug Maintenance (bugmaster)
Changed in evergreen:
milestone: 3.0.1 → 3.0.2
Revision history for this message
Galen Charlton (gmc) wrote :

Pushed to master, rel_3_0, and rel_2_12. Thanks Rogan and Cesar!

Changed in evergreen:
status: Triaged → Fix Committed
Evergreen Bug Maintenance (bugmaster)
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.