Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Holdingpen: do not blindly overwrite legacy #3618

Open
fschwenn opened this issue Aug 29, 2018 · 1 comment
Open

Holdingpen: do not blindly overwrite legacy #3618

fschwenn opened this issue Aug 29, 2018 · 1 comment

Comments

@fschwenn
Copy link
Contributor

fschwenn commented Aug 29, 2018

Since the synchronization between labs and legacy is not instantaneous, there is time frame where a record changes on both sides independently.

Expected Behavior

Changes on labs side (e. g. record update via arXiv update or publisher information) should flow back to legacy with the timestamp in 005 from the version of the record on labs.
Or some other mechanism which ensures, that if a record is changed on legacy between the two synchronisations, it is not blindly overwritten at legacy.

Current Behavior

Changes on labs are uploaded in correct mode on legacy and hence overwrite changes made meanwhile on legacy.

Context

It is a rather rare case if everything works properly. But nevertheless, if we want to do a lot of stuff via labs-worklflow and at the same time curate on legacy, it will happen.
Especially if the synchronisation is delayed for some technical reasons this becomes a severe issue. E.g. today (2018-08-30) at 9 o'clock all the arXiv updates submitted to legacy between 4 and 5 o'clock are still waiting in the cue (together with a lot of bibedit jobs by cataloguers).

@tsgit
Copy link
Contributor

tsgit commented Aug 30, 2018

this behavior is made more likely due to high priority (5) of legacy bibedit bibuploads, which enables them to leapfrog even already scheduled bibuploads from labs at lower priority.
I think labs bibuploads are usually in mode replace and not mode correct as Florian stated above.

The timestamp in controlfield 005 is used on legacy to avoid competing edits/changes

if a change is made based on a copy (snapshot) of the record at time A and another edit/change is made and that one is processed first on legacy, then the legacy record will have timestamp B -- the time the bibupload was processed. if A != B then bibupload for the first change will be rejected and entered into the legacy holdingpen (at least I think that should happen)

however nobody looks at the legacy holdingpen -- so that edit is also likely lost.

legacy bibedit itself can/may warn curators interactively if the underlying record meanwhile changed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants