'mod-quick-marc' supports the update for not only MARC Bibliographic but also MARC Holdings records (in Lotus
'mod-quick-marc'will also support MARC Authority records) it means that both types of records need to support optimistic locking. The flow of updating Inventory Instances/Holdings includes the following modules:
Due to the requirement to provide a
'_version' for Inventory Instance/Holdings
'mod-quick-marc' should introduce a new property for the schema.
and also should be included into 'required' section
'relatedRecordVersion' property will address the corresponding version for
'mod-quick-marc' Bibliographic and Holdings records.
'ui-quick-marc' module is fetching the Inventory instance when user clicks on 'Edit MARC bibliographic record'.
'mod-quick-marc' sent a version for update, '
mod-source-record-manager' should handle property.
The main purpose of
'mod-source-record-manager' in scope of Optimistic locking feature is transfer the value to the next chain entry. The model, which is used for update process is ParsedRecordDto.json and stored in
It should be extended to have the version from
Then, the payload with
"relatedRecordVersion" should be sent to
'mod-source-record-storage' without any code changes, except tests.
'mod-source-record-storage' as well as
'mod-source-record-manager' only transfer the
"relatedRecordVersion" property. So, for this module we also do not have to change the existing code, except tests.
The first step is to move property
"relatedRecordVersion" to event payload in
During marshalling and unmarshalling(converting a Java object into/from JSON) for Inventory Instance
'_version' was not correctly mapped due to property naming inconsistency, to fix it, we should set the value explicitly
This adjusting should be done only for Inventory Instance.
adjustVersionField method is no longer needed as this commit fixes inconsistency for
Scope of the work
You can find the work needed for supporting optimistic locking below in the table
|Module||Jira issue||PR/branch||Story points|
Questions and Answers
why property has name as "relatedRecordVersion"
and not something identifying entity like "qmHoldingsId", "qmBibliographicId"?
making either two representations or two different properties(which should be required) complicates the existing code base.
That is why we decided to use one common property for two objects that identifies the same property.