2022-10-03 - Data Migration Subgroup Agenda and Notes
- Darsi Rueda
Date
Attendees
Darsi Rueda jpnelson Tod Olson Carol Sterenberg Jeff Fleming Ian Walls
Meeting Link
- https://zoom.us/j/204980147
- password: folio-lsp
Link to Recordings
Discussion items
Time | Item | Who | Notes |
|---|---|---|---|
| Migration demo for hbz | Ingolf Kuss | Do on Oct 17 so it can be announced in the agenda and get more participation | |
| 5 | Optimistic locking | MODINVSTOR-924 - Getting issue details... STATUS Sprint has been assigned, and it is marked for Nolana R3 2022. Can’t make it a flag if it’s supposed to have more locked down permissions, needs to be a separate end point. Is optimistic locking a “core function” of FOLIO or not? Do other systems have optimistic locking? Koha no, Symphony no. Other sites say it happens more regularly (and this is why they wanted it). | |
| 20 | Migrating loans | (Tod) UChicago went from Ole db to locally hosted FOLIO db. Backward engineering how data had to be in FOLIO for the loan to be in the same state. Not really a fan of that approach, although it avoided some problems (and was maybe faster). In retrospect, not a terrific use of time. (Jeff) Duke: checkout-by-barcode, then circulation-loans with a PUT to correct the due date. Otherwise would automatically go to lost. Depending on certain status, does claims returned. (Does a FOLIO claim-item-returned). Bywater goes straight to the storage layer, cuz small scale. When comes to notices, they send on demand notices as a follow up to the migration. Ian has a workflow, given a set of loans, send notices in a given template. Can set the #of renewals when doing this. Needs to be connected to a policy that allows that number of loans (but only in a “this is right” sense, the db will let you do it). Having to turn off notices/email isn’t an issue with the storage approach. | |
| Migration status reports | Stanford going back to fix issues reported during QA process. Changing our strategy, used to be “load a library at a time” but now going to redo and do “all holdings/items on an instance.” Will redo our full load this week, and will load lots to see how we scale. Stanford going “barcode free” on user cards/records. But FOLIO requires a barcode for checkout. We’ll put the “chipID” of the card into the user record instead. No validation on user barcode filed per Ian. Jeff/Duke working on loading marc holdings. There’s an issue with how they had their locations set up. With dashes in-between, quickmarc doesn’t like this. (Also problem in matching in Data Import. Has problem matching on location if permanent location has a dash in it. UIDATIMP-1276 - Getting issue details... STATUS ) There’s a regular holdings in inventory. We’ve been loading it fine, but now when we can use them in quickmarc, in the editor, has problems in the 852. Jeff: has been working on requests. Not going to migrate fines at Duke. Next he’ll be looking at closed orders, but not through api. Instead will send them on to IndexData to do. Ian: most sites don’t do fines, if they do they bring it over as a static fine, not try to tie it to a loan. Sometimes tie it to an item. The amount of time to migrate fines, how much $$ does that take vs how much all those fines are worth? Tod: UChicago migrated fines. (David Bottorff has details.) | ||