Bibliographic record merging should update the MARC leader when deleting a record

[Kathy Lussier]

Evergreen version: 2.6

When merging bib records, in the Leader, position 05 - Record Status of the deleted record, the code is not changed to "d," for deleted, as it is when a record is simply deleted within the client.

[Sharon Douglas (onefish7)]

version 2.10.6 experiencing the exact situation

[Mike Rylander (mrylander)]

I think this should be handled by a database trigger, setting the leader 05 to 'd' on delete and, most likely, 'n' on "undelete". Question: should the field be check and set to 'n' (or other) if it is being inserted for the first time and is currently set to 'd'?

[Rogan Hamby (rogan-hamby)]

Just to expand it even more should we mark it 'c' when it's edited since presumably it has been revised?

[Christine Morgan (cmorgan-z)]

Mike and Rogan, I would say yes to both questions since you might want the record status to reflect it's life in your database.

[Garry Collum (gcollum)]

This may be a separate bug, but it is closely related. The edit_date column in biblio.record_entry for the deleted record is also not updated after the merge. I think it should be for query purposes.

[Rogan Hamby (rogan-hamby)]

I've done some work on this but it needs some more testing on my end. I'll
try to get around to working on it more soon. Should an update to
edit_date on delete be on this or a separate bug ticket? I think of it as
a separate thing but I'll defer to a wider opinion.

On Mon, Sep 25, 2017 at 3:46 PM, Garry Collum <email address hidden>
wrote:

> This may be a separate bug, but it is closely related. The edit_date
> column in biblio.record_entry for the deleted record is also not updated
> after the merge. I think it should be for query purposes.
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> Matching subscriptions: evergreenbugs
> https://bugs.launchpad.net/bugs/1387722
>
> Title:
> Bibliographic record merging should update the MARC leader when
> deleting a record
>
> Status in Evergreen:
> Confirmed
>
> Bug description:
> Evergreen version: 2.6
>
> When merging bib records, in the Leader, position 05 - Record Status
> of the deleted record, the code is not changed to "d," for deleted, as
> it is when a record is simply deleted within the client.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1387722/+subscriptions
>

[Kathy Lussier (klussier)]

I agree it's a separate bug.

[Rogan Hamby (rogan-hamby)]

I've pushed a working branch for this to: user/rogan/lp1387722_set_leader_delete_status

Following Mike's advice I did it as a database trigger on the biblio.record_entry row. I've tested it under current master and it works cleanly.

On insert it sets it to 'n', on update and delete flag is false (including undelete) it sets to 'c' and on update with delete set to true it sets it to 'd'.

[Jane Sandberg (sandbergja)]

Rogan, since this introduces some new behavior, could you please include a short release note in your branch?

[Rogan Hamby (rogan-hamby)]

Will do.

[Rogan Hamby (rogan-hamby)]

Jane,

here it is: user/rogan/lp1387722_record_leader_updates_release_note

[Rogan Hamby (rogan-hamby)]

upgrade script added to tip of user/rogan/lp1387722_set_leader_delete_status

[Jane Sandberg (sandbergja)]

Thanks for your work on this, Rogan. I wonder if a PGTap test to test your sweet new biblio.set_record_status_in_leader() function might also be helpful. Thoughts?

[Rogan Hamby (rogan-hamby)]

Looking at it I decided to make a tweak so in the progress I squashed everything into a new branch: patch, upgrade script, release notes and pgtap test:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=af50a59b300a2218d08e4b22cc95dfa7c806b428

user/rogan/lp1387722_record_leader_updates_squashed

[Jane Sandberg (sandbergja)]

That looks great, Rogan!

[Ben Shum (bshum)]

Fixed up the commit to add details and pushed to master for future releases.

[Ben Shum (bshum)]

Okay, I reverted this change because it was causing unexpected problems elsewhere with the perl livetests.

Apparently, the URI triggers are seemingly being run twice. This led to concerto dataset getting busted with extra rows for call numbers, which shifted all the copies, making all the live tests unhappy. I don't think we want the database to be churning extra runs of the asset.uri creation/deletion, so let's look at this more closely.

Removing pullrequest and adding repatch note.

[Rogan Hamby (rogan-hamby)]

Interesting. I’ll take another look at this with 856s.

On Wed, May 2, 2018 at 01:17 Ben Shum <email address hidden> wrote:

> Okay, I reverted this change because it was causing unexpected problems
> elsewhere with the perl livetests.
>
> Apparently, the URI triggers are seemingly being run twice. This led to
> concerto dataset getting busted with extra rows for call numbers, which
> shifted all the copies, making all the live tests unhappy. I don't
> think we want the database to be churning extra runs of the asset.uri
> creation/deletion, so let's look at this more closely.
>
> Removing pullrequest and adding repatch note.
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> Matching subscriptions: evergreenbugs
> https://bugs.launchpad.net/bugs/1387722
>
> Title:
> Bibliographic record merging should update the MARC leader when
> deleting a record
>
> Status in Evergreen:
> Incomplete
>
> Bug description:
> Evergreen version: 2.6
>
> When merging bib records, in the Leader, position 05 - Record Status
> of the deleted record, the code is not changed to "d," for deleted, as
> it is when a record is simply deleted within the client.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1387722/+subscriptions
>

[Rogan Hamby (rogan-hamby)]

Currently back to working on this. I'm not seeing it duplicate any acn rows but I am seeing some errors related to it on other tests so I'm working through those now.

[Rogan Hamby (rogan-hamby)]

I thought I had updated this in the past but apparently not. I'd like to gather thoughts from others. The reason this was causing other tests to fail was not due to functionality but how those tests loaded marc for testing. The interaction of updating the marc records interfered with the testing but in a manner that is the purpose of fixing the bug. My memory is vague about which bug it was right now but either we would need to have those other tests change or go a different route with this or mark won't fix.