Authority update propagation should update bib record editor and edit_date

[Bill Erickson]

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)]

Potential implementation. Needs release notes.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1588948-auth-prop-sets-bib-edit-data

[Bill Erickson (berick)]

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.

[Bill Erickson (berick)]

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.

[Bill Erickson (berick)]

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

[Bill Erickson (berick)]

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)]

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)]

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)]

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

[Bill Erickson (berick)]

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() ?

[Mike Rylander (mrylander)]

Something like this:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp1588948-auth-prop-sets-bib-edit-data

[Bill Erickson (berick)]

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:

http://git.evergreen-ils.org/?p=working/Evergreen.git;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)]

Master has it. Thanks, Bill!