Skip to end of banner
Go to start of banner

2022-07-11 - Data Migration Subgroup Agenda and Notes

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Date

Attendees

Darsi Rueda


Meeting Link

Link to Recordings

Discussion items

Time

Item

Who

Notes


Optimisitic locking workarounds


Stanford tested two scenarios using the same Okapi endpoint that we use in our DAG (/instance-storage/batc/synchronous?upsert=true). In both tests, I added a new _version property with a value of 1.

For the first test, all the records existed in FOLIO and the upsert POST succeed with each record's _version property incremented to 2.

For the second test, the records did not exist in FOLIO and the upsert POST succeed and each record's _version property stayed as 1.


“Upsert works” Jira

MODINVSTOR-924  - new Jira asking for a new api that disables optimistic locking while api runs
Lots of comments on this Jira both for and against. Some folks worried about bulk updates happening during work day and having conflicts.  Others supporting need for multiple loads during migration process, and for batch instance updates.

Julian includes workarounds, including disabling optimistic locking:
ALTER TABLE instance DISABLE TRIGGER set_instance_ol_version_trigger;
ALTER TABLE instance ENABLE TRIGGER set_instance_ol_version_trigger;

set_instance_ol_version_trigger could disable optimistic locking at the database level, for instances, holdings, items.  Postgres commands.

Decided we will do some experimenting with disabling optimistic locking and load some records.  Then enable and load some more with version number, what problems will we run into?

We also should continue to fill out our document with the impact of this problem, AND comment on the Jira ticket so the develops see our comments immediately.  So we’ll advocate for ourselves on two fronts.









Action items

  •  
  • No labels