[FOLIO-1499] Inventory changes with potential impact on data load Created: 14/Sep/18 Updated: 18/Jan/19 |
|
| Status: | Open |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P3 |
| Reporter: | Niels Erik Nielsen | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||
| Sprint: | |||||||||||||||||
| Development Team: | Core: Platform | ||||||||||||||||
| Description |
|
A heads up Wayne Schneider that following upcoming changes to Inventory could potentially break current data load procedures (I don't know if they would): Foreign key constraints between item, holdings_record, instance: Dictates order of inserts and deletes;
|
| Comments |
| Comment by Wayne Schneider [ 15/Sep/18 ] |
|
Thanks, Niels Erik Nielsen. As long as the sample data in mod-inventory-storage is updated to match the schema changes, and the MODS loader in mod-inventory generates an HRID (Marc Johnson?), we should be fine. |
| Comment by Niels Erik Nielsen [ 16/Sep/18 ] |
|
Okay, good, thanks. MODS loader, that must be the IngestMessageProcessor in mod-inventory; it generates a UUID for the HRID, for now. (I know I ought to better understand the exact role of this piece.) Eventually Instance HRIDs are supposed to be either generated by a sequencer in mod-inventory/mod-inventory-storage (on the pattern "in<99999999>") or be a unique identifier loaded from the source. |
| Comment by Marc Johnson [ 17/Sep/18 ] |
|
Niels Erik Nielsen My understanding is that the MODS loader will be deprecated and removed, once the reference environments use the data loader (or its successor, depending upon when that is due) to load sample instance records (and I imagine some kind of default holding and item). There is likely limited value in becoming more familiar with this part of the code. Wayne Schneider We may need to be prepared for similar issues to recently, relating to regression test execution on pull requests (as soon as the sample records are changed in master, there will likely be a discrepancy between them and the version of the module hosted on folio-snapshot-stable). Given that my understanding is that the human readable ID is intended to not be a UUID, we may want to prepare people using the reference systems, as these kinds of discrepancies have been raised as bugs (particularly related to the records loaded via the MODS import). I asked a few questions about the generation of human readable IDs on
|
| Comment by Niels Erik Nielsen [ 18/Sep/18 ] |
|
Yes, eventually all records are intended to have these IDs assigned. |