Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODQM-166

Table of Contents
excludeAdditional information:

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. 

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

and also should be included into 'required' section

Code Block
"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 

Image Added

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

Code Block
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

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

This adjusting should be done only for Inventory Instance.

Note

the adjustVersionField method is no longer needed as this commit fixes inconsistency for '_version' field.


Scope of the work

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

ModuleJira issuePR/branchStory points
Back-end
mod-quick-marc

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODQM-167

https://github.com/folio-org/mod-quick-marc/pull/1232

data-import-raml-storage

https://github.com/folio-org/data-import-raml-storage/pull/231

mod-source-record-manager

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODSOURMAN-577

https://github.com/folio-org/mod-source-record-manager/tree/MODSOURMAN-5771

mod-source-record-storage

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODSOURCE-387

https://github.com/folio-org/mod-source-record-storage/tree/MODSOURCE-3871

mod-inventory

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODINV-542

https://github.com/folio-org/mod-inventory/pull/4041
Front-end
ui-quick-marc

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUIQM-153



Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUIQM-162



Testing
Rancher

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODQM-168




Questions and Answers


QA

why property has name as "relatedRecordVersion" 

and not something identifying entity like "qmHoldingsId", "qmBibliographicId"?

'mod-quick-marc' uses one representation model  for both MARC Bibliographics and MARC Holdings records and 

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. 



Additional information: