Details
-
New Feature
-
Status: Open (View Workflow)
-
P2
-
Resolution: Unresolved
-
None
-
None
-
Core: Platform
-
-
0
-
R4
-
R1
-
R1
-
R1
-
R1
Description
How
Optimistic Locking functionality in an RMB module is enabled for selected tables by changing configuration in the schema.json file. See https://github.com/folio-org/raml-module-builder#optimistic-locking. OL changes the behavior of the API and hence requires a major interface change.
Where
It has been discussed that OL 'failOnConflict' should be enabled for interfaces where there is a risk of concurrent access (and collisions). In mod-inventory storage this is done for instances/holdings/items.
What
POs: indicate interfaces where OL should be enabled by creating a specific backend issue and linking to this feature.
TestRail: Results
Attachments
Issue Links
- defines
-
UXPROD-3058 Optimistic Locking
-
- In progress
-
- is defined by
-
MODINVSTOR-708 enable 'failOnConflict' for instances/holdings/items interfaces
-
- Closed
-
-
MODINVSTOR-713 Enable support for optimistic locking (failOnConflict) in instances/holdings/items (part1)
-
- Closed
-
-
MODNOTES-175 Optimistic locking for note_data
-
- Closed
-
-
MODORDSTOR-225 Optimistic locking for pieces/po_line/purchase_order
-
- Open
-
-
MODORGSTOR-106 Optimistic locking for organizations/contacts/interfaces
-
- Open
-
-
UXPROD-3089 Inventory. Implementing Optimistic Locking
-
- Closed
-
- relates to
-
UXPROD-1752 Prevent update conflicts (via optimistic locking): platform support for detection
-
- Closed
-
-
UXPROD-3048 Check that generated sequences cannot produce duplicates
-
- Open
-
-
UXPROD-3089 Inventory. Implementing Optimistic Locking
-
- Closed
-