MODQM-166 Spike: investigate effort to support optimistic locking

MODQM-166 - Getting issue details... STATUS

Problem:

Optimistic locking feature was merged into a 'mod-inventory-storage' module with this commit and brokes existing update flow for Inventory Instances/Holdings via 'mod-quick-marc'.

Goal: 

Support optimistic locking feature for Lotus(R1 2022) release.

Proposed Solution:

'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:

• mod-quick-marc
• mod-source-record-manager
• mod-source-record-storage
• mod-inventory
• data-import-raml-storage

mod-quick-marc changes

Due to the requirement to provide a '_version' for Inventory Instance/Holdings 'mod-quick-marc' should introduce a new property for the schema. 

"relatedRecordVersion": {
	"type": "string",
	"description": "Information related to '_version' of the record"
}

and also should be included into 'required' section

"required": [
	"parsedRecordDtoId",
	"suppressDiscovery",
	"instanceId",
	"leader",
	"fields",
	"relatedRecordVersion"
]

This 'relatedRecordVersion' property will address the corresponding version for 'mod-quick-marc' Bibliographic and Holdings records.

ui-quick-marc changes

On UI 'ui-quick-marc' module is fetching the Inventory instance when user clicks on 'Edit MARC bibliographic record'. 

The response contains '_version' property, so it can be moved to 'mod-quick-marc' model.

Once 'mod-quick-marc' sent a version for update, 'mod-source-record-manager' should handle property.

mod-source-record-manager changes

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 'data-import-raml-starage' lib.

It should be extended to have the version from 'mod-quick-marc' module.

Then, the payload with "relatedRecordVersion" should be sent to 'mod-source-record-storage' without any code changes, except tests.

mod-source-record-storage changes

'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.

mod-inventory changes

When 'mod-inventory' receives the payload it comes with "relatedRecordVersion" property in ParsedRecordDto.json which has nothing in common with Inventory Instance or Holdings. 

The first step is to move property "relatedRecordVersion" to event payload in QuickMarcKafkaHandler 

then,  the value should be mapped to '_version' for corresponding handlers - HoldingsUpdateDelegate and InstanceUpdateDelegate.

private void fillVersion(HoldingsRecord existingHoldingsRecord, Map<String, String> eventPayload) {
	if (eventPayload.containsKey(QM_RECORD_VERSION_KEY)) {
		existingHoldingsRecord.setVersion(Integer.parseInt(eventPayload.get(QM_RECORD_VERSION_KEY)));
	}
}

During marshalling and unmarshalling(converting a Java object into/from JSON) for Inventory Instance 

property '_version' was not correctly mapped due to property naming inconsistency, to fix it, we should set the value explicitly

private void adjustVersionField(JsonObject existing) {
	existing.put(VERSION_KEY, existing.getString("version"));
	existing.remove("version");
}

This adjusting should be done only for Inventory Instance.

Scope of the work

You can find the work needed for supporting optimistic locking below in the table

Questions and Answers

Additional information: