Authority update propagation should update bib record editor and edit_date

Bug #1588948 reported by Bill Erickson on 2016-06-03
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Evergreen 2.10

Modifying an authority record causes updates to propagate to linked bib records. These changes should include an updated value for edit_date and editor on the modified bib records.

We can copy the editor value directly from the authority record, so whoever edits the authority record also shows as the last editor of the bib record.

I think this should include a new global flag to enable / disable the behavior. Specifically, I could imagine disabling the feature during bulk authority updates.

Bill Erickson (berick) wrote :

PGTAP test and release notes pushed.

Note the PGTAP test is meant to be a general purpose authority-to-bib propagation test file, covering basic data propagation as well as the editor/edit_date changes, hence the lack of LP# tag number on the test file.

tags: added: pullrequest
Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
milestone: none →
Bill Erickson (berick) wrote :

Removing pull request tag, pending a code change to only modify bib editor and edit_date when the authority record propagation resulted in a change in the bib record.

tags: removed: pullrequest
Bill Erickson (berick) wrote :

Change pushed to update bib record editor / edit_date only when an authority propagation results in a modified bib record.

tags: added: pullrequest
Bill Erickson (berick) wrote :

As a side effect of the above, no attempt will be made to update a bib record when an authority record propagation has no effect on the bib's MARC. IOW, trivial authority record updates (i.e. not modifying controlled fields) will no longer result in unnecessary updates of all linked bibs.

Mike Rylander (mrylander) wrote :

Bill, can you think of a way to avoid even looking at the bibs? My thought was to check the main heading value from the old and new row versions at the authority level and if it's the same just skip the bib side altogether. I think that will be MUCH faster than looping through potentially thousands of bibs and calling the merge procedure to make sure that they don't change. Thoughts?

Bill Erickson (berick) wrote :

Skipping unnecessary bib updates would be a big win. Mike, are you thinking something like:

IF OLD.heading <> NEW.heading ...

If so, I think that would cover it.

Mike Rylander (mrylander) wrote :

Yep, something along those lines is what I was thinking of.

Bill Erickson (berick) wrote :

If I understand correctly, to use the updated NEW.heading value, we'd have to modify the trigger names so that update_headings_tgr() runs before aaa_auth_ingest_or_delete().

Fortunately, update_headings_tgr() does not appear to have any side effects beyond modifying NEW.heading and NEW.simple_heading.

Any concerns about renaming update_headings_tgr() to aaaa_update_headings_tgr() ?

Bill Erickson (berick) wrote :

Thanks, Mike.

Tested the commit and confirmed NEW.heading is changed before propagation occurs and confirmed propagation is only attempted when NEW.heading differs. PGTAP tests still pass.

Rebased, added comment to release notes about speed-up, and pushed sign-off back to source branch:;a=shortlog;h=refs/heads/user/berick/lp1588948-auth-prop-sets-bib-edit-data

I believe sign-off's on my commits are all that remains.

Mike Rylander (mrylander) wrote :

Master has it. Thanks, Bill!

Changed in evergreen:
status: New → Fix Committed
Changed in evergreen:
milestone: → 2.11-beta
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