Remove $0 from bib control field(s) when authority record is deleted

Bug #1164189 reported by Mark Cooper
48
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Evergreen
Triaged
Wishlist
Unassigned

Bug Description

Wishlist

Evergreen 2.4 -- master.

There's a question in authority.indexing_ingest_or_delete, in the delete section: "Should remove matching $0 from controlled fields at the same time"?

The answer should be yes! Retaining the $0 associated with a deleted authority is misleading -- it's much clearer what is going on if the $0 is for active/valid/non-deleted bib links only.

For a specific example consider the concerto data set.
There's a Harry Potter record from MVLC with references to authority records from their system.
If I import the real Rowling authority and run authority_control_fields.pl here's the result:

=100 1\$0(MVLC) 442287$aRowling, J. K.$0(CONS) 1

The useless reference to the non-existent MVLC authority is still there, along with the real, existing in the database record.
If I then delete the Rowling authority (#1) and run authority_control_fields.pl again the field remains the same, with two useless $0 subfields.

Ben Shum (bshum)
Changed in evergreen:
status: New → Triaged
tags: added: wishlist
description: updated
Revision history for this message
Srey Seng (sreyseng) wrote :

Hello,

Here is a work in progress branch for this "bug":

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sreyseng/lp1164189-remove-linked-subfield-on-auth-delete-fix-v2

Any feedback & testing is much appreciated!

Thanks!

Revision history for this message
Mike Rylander (mrylander) wrote :

A few comments:

1) attacking this problem is a good idea
2) the regexp is likely too strict, there's no reason that numbers or lower-case letters might show up between the ()s, nor that there will even be (). we only look for a string of numbers at the end of the field in other cases
3) this will fall victim to the same underlying issue as authority merge, where the cascade of updating and reingesting many records will cause a timeout of the user-level delete action. See: bug 1193490

Particularly because of (3), this has a strong chance of generating user-level failures where there were none before. So, because this is more of an aesthetic issue than a data integrity one, my opinion is that this should wait until there is movement on bug 1193490 before applying.

I haven't the tuits ATM, but the problem addressed here might also benefit from some more thought WRT the possible queued reingest world.

Revision history for this message
Srey Seng (sreyseng) wrote :

Thanks a bunch for reviewing this. I definitely see the concerns expressed here and agree that work on this bug would benefit from leveraging any solutions provided in bug 1193490 .

Elaine Hardy (ehardy)
tags: added: cat-authority
removed: authority
Changed in evergreen:
importance: Undecided → Wishlist
tags: removed: wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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