Metarecords are not being maintained properly

Bug #1488655 reported by Blake GH on 2015-08-25
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
2.10
Medium
Unassigned

Bug Description

A quick test on 2.7.0:

1. Find a group of records for a metarecord:

select * from metabib.metarecord a where master_record in(select source from metabib.metarecord_source_map where metarecord=a.id)
and id in
(select metarecord from (select metarecord,count(*) from metabib.metarecord_source_map mmsm, biblio.record_entry bre where bre.id=mmsm.source and not bre.deleted group by metarecord having count(*) > 2) as b ) LIMIT 100

2. Update the MARC for the master record in such a way that the resulting fingerprint is totally different than the rest of the group.

3. At this point, you can run this query:
select metarecord,source
from metabib.metarecord_source_map a where metarecord = {CHOSEN METARECORD ID}

and you will find that your record is still apart of the group even with the fingerprint difference.

This query will show the group's fingerprints:

select id,fingerprint from biblio.record_entry where id in(
select source
from metabib.metarecord_source_map a where metarecord= {CHOSEN RECORD ID}
)

4. Update config.internal_flag 'ingest.reingest.force_on_same_marc' = true

5. Update/reingest the group of bibs:

update biblio.record_entry set id=id where id in(
select source
from metabib.metarecord_source_map a where metarecord= {CHOSEN RECORD ID}
)

6. The only thing that changes now that you have reingested the group, is the master_record will point to another member of the group

I believe that this is a bug in metabib.remap_metarecord_for_bib
and might be related to
https://bugs.launchpad.net/evergreen/+bug/953439

Relevant IRC discussion:
http://irc.evergreen-ils.org/evergreen/2015-08-25#i_198627

Our database contains metarecords that have a master record pointing to a record that is not a member of the group. This query identifies that situation:

select * from metabib.metarecord a where master_record not in(select source from metabib.metarecord_source_map where metarecord=a.id)
and id in
(select metarecord from (select metarecord,count(*) from metabib.metarecord_source_map mmsm, biblio.record_entry bre where bre.id=mmsm.source and not bre.deleted group by metarecord having count(*) > 1) as b )

These are probably related issues. Deleted records also seem to remain in the metarecord group. Which might be OK, not sure.

Kathy Lussier (klussier) on 2016-07-06
tags: added: fingerprint metarecords
Galen Charlton (gmc) wrote :

I've tracked this down, at least in part, to a bug in the logic in metabib.remap_metarecord_for_bib() for deleting the old metarecord mapping (and possibly the metarecord) when the bib's fingerprint has changed.

Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
status: New → Confirmed
Galen Charlton (gmc) wrote :

Patches available at the tip of the user/gmcharlt/lp1488655_improve_metarecord_remapping branch in the working/Evergreen repository:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1488655_improve_metarecord_remapping

Changed in evergreen:
milestone: none → 2.11.1
assignee: Galen Charlton (gmc) → nobody
tags: added: pullrequest
Changed in evergreen:
importance: Undecided → Medium
Rogan Hamby (rogan-hamby) wrote :

I've tested the patch and it looks good to me. I've pushed a sign off as well.

Galen Charlton (gmc) on 2016-11-16
Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers