[UXPROD-2994] Optimistic Locking: coordinate rollout of "failOnConflict" to selected modules and APIs Created: 15/Mar/21 Updated: 29/Jun/22 |
|
| Status: | Open |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | TBD |
| Type: | New Feature | Priority: | P2 |
| Reporter: | Jakub Skoczen | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | R2, cornell-priority, platform-backlog | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Development Team: | Core: Platform | ||||||||||||||||||||||||||||||||||||||||||||||||
| PO Rank: | 0 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R4 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | 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. |
| Comments |
| Comment by Tom Wilson [ 24/Mar/21 ] |
|
All "interfaces" in which there could be conflict should have OL implemented. Any of the areas that have large data stores, e.g., users, inventory, srs, etc., would likely have conflicts between individual users and/or a user and an import process. |
| Comment by Jakub Skoczen [ 12/Apr/21 ] |
|
Tom Wilson Agree. I have created
|
| Comment by Kelly Drake [ 12/Apr/21 ] |
|
Jakub Skoczen - will you be reaching out to the dev teams, or should I bring this to the POs? |
| Comment by Jakub Skoczen [ 20/Apr/21 ] |
|
Kelly Drake What do you think is the best way forward?. So far I have created the rollout ticket for mod-inventory-storage (
|
| Comment by Ann-Marie Breaux (Inactive) [ 20/Apr/21 ] |
|
Hi Kelly Drake and Jakub Skoczen If this work is just about to land on several dev teams, we need to be clear about when this work needs to be delivered. My feeling is that we're too late for Juniper. If it needs to be part of Iris, then we need to understand the size of the work and have stories for every team/app where it's relevant. Thank you! |
| Comment by Jakub Skoczen [ 21/Apr/21 ] |
|
Ann-Marie Breaux Kelly Drake I agree. I think Juniper is too short and too packed to fit this in. And this is a fairly disruptive change. How about we work with the POs to have the stories defined in Juniper but have the dev work happen in Kiwi? |
| Comment by Kelly Drake [ 21/Apr/21 ] |
|
Jakub Skoczen and Ann-Marie Breaux I've added this to the next PO meeting agenda. This suggested timeline may not work for all teams but it's worth a shot. Do you think we should use that meeting to get the POs starting in the process of defining the necessary stories, or should that work be done individually? |
| Comment by Ann-Marie Breaux (Inactive) [ 21/Apr/21 ] |
|
Jakub Skoczen and Kelly Drake I agree that Juniper is too short. I'm totally fine with Kiwi so long as the POs understand what needs to be done (hopefully some sort of model story or stories that we can copy) and that the SMEs understand this will take some of the Kiwi dev capacity for a number of dev teams. |