Comment 2 for bug 1553287

Kathy Lussier (klussier) wrote :

After asking about this in IRC last week, I tried a new reingest with the ingest.reingest.force_on_same_marc internal flag enabled. I see the same behavior:

* The reingest creates the new fingerprints with the part information as expected.
* The reingest also creates new mappings to a new master record when appropriate.
* However, it does not remove the old map to the previous master record. We then end up with duplicate source record entries in metabib.metarecord_source_map.

I'm guessing this is related to bug 1488655

If this change to the fingerprint is added, then, it's going to cause problems for upgraded database.

My question is whether we need to wait for 1488655 to be fixed before we can add a change to config.biblio_fingerprint to the code or is there something else that can be done during the upgrade to handle those metabib.metarecord_source_map entries that are not being deleted?

We would love to see this change to the fingerprint introduced since the current fingerprint can lead to some odd groupings when there are series using this subfield.