...
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. -- Could disable all through testing phase, and always set _version = 1. Or at least could test this. | ||
Optimistic locking workarounds | Ian using Data Import app to do a 40K migration. It deals with the versioning issue of optimistic locking. Only does for inventory. Uses batch endpoints for holdings and items. (Bywater instances are hosted by EBSCO.) | ||
“Upsert works” Jira | MODINVSTOR-924 - new Jira asking for a new api that disables optimistic locking while api runs Julian includes workarounds, including disabling optimistic locking: 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? | ||
...