You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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
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).
The text was updated successfully, but these errors were encountered: