| Table of Contents | ||
|---|---|---|
|
...
Q. When a library upgrades to a new version of Data Import (or more specifically, new versions of the modules that comprise Data Import, does the library need to load the sample data for any of the Data Import modules (e.g. mod-data-import, mod-data-import-converter-storage, mod-data-import-processing-core. mod-source-record-manager, mod-source-record-storage) If not, how do new default profiles get added?
A. There is no need to do anything specific. Default profiles are loaded automatically once a module is enabled for a tenant. New profiles added in a newer release version are also created during the module upgrade with no additional work from the users doing the upgrade.
Q. Data in an Inventory Instance that is based an underlying SRS MARC Bibliographic record is refreshed against the tenant's most recent MARC Bibliographic-to-Inventory Instance map. What triggers the refresh of an Instance with Source = MARC?
...
- See the third script on Scripts for Inventory, Source Record Storage, and Data Import Cleanup
- And further details MODDATAIMP-567: Script to refresh Instances against an updated MARC Bib-to-Inventory Instance map
Q. Are there any best practices for moving SRS bibs from one FOLIO tenant to another?
It is common practice to use an export - edit - reload workflow to maintain metadata with Data Import and Export.
Files may also be exported from one FOLIO tenant (library) and then imported to a different FOLIO tenant. The MARC 999 ff field will contain the UUIDs for the first tenant's SRS MARC record and for the Inventory Instance. Users are encouraged to follow this best practice: manually remove the 999 ff field from the exported file before importing to the second tenant, so that the second tenant can create a new 999 ff with completely unique SRS and Instance UUIDs. If not removed, it will not create a problem within either tenant, but (as of August 2020), the SRS UUID will be the same for both tenants. This can be revisited and refactored if significant issues are identified.
Q. Please explain the Administrative data in source-record-storage for the MARC records (not the MARC data, the non-MARC data associated with the MARC record)
A. See below for each field in orange, sample data in green, and explanation in black.
"id":"908de854-977e-4fc4-b99b-438af3eed2a1" is the UUID for that particular generation of the record. For generation 0 it matches the 999 ff $s and the matchedId. For every generation after 0, it’s a new UUID (so that the incrementing copies of the SRS MARC can be organized)
"snapshotId":"cf7436ec-fa78-485a-b154-7f1545233d01" (same as jobExecutionId): UUID is analogous to the Job UUID in the Log UI.
"matchedId":"908de854-977e-4fc4-b99b-438af3eed2a1" the UUID that’s in 999 ff $s and an id for record with generation 0; it does not change; helps to keep the versions of the same SRS MARC Bib organized and related
"generation":0 generation: starts at 0 and increments. Generation is set for each record before storing it in the database. A previous version of this record is checked, and if it exists, the generation number is incremented by 1 before being saved to the database.
"recordType":"MARC"
"rawRecord": { "id":"908de854-977e-4fc4-b99b-438af3eed2a1" contains the raw MARC record from the import file, in a blob
"content": ...
"parsedRecord": { "id":"908de854-977e-4fc4-b99b-438af3eed2a1" contains the parsed MARC record, in MARC fields
"content":"fields":
"001":"in00000000003" Instance HRID; when a MARC record is firs created in SRS, the corresponding Instance is created in Inventory, and then the Inventory Instance HRID and UUID are sent to SRS. SRS moves any existing 001 data to an 035 field, and precedes that number with any 003 data, in parentheses, e.g. 001 12345 and 003 OCoLC become 035 $a (OCoLC)12345. Then the Instance HRID is placed in the (now-empty) 001 field of the SRS MARC record.
All the other MARC data
"999": { "ind1":"f", "ind2":"f", "subfields": [ { "s":"908de854-977e-4fc4-b99b-438af3eed2a1" }, { "i":"5289d4af-d755-47e5-a5fe-e76737163bfa" } ] } } ]
"leader":"02598cam a2200505Ii 4500" (The leader data is store at the end of the MARC record, instead of the beginning)
"deleted":false
"order":2
"externalIdsHolder":
"instanceId":"5289d4af-d755-47e5-a5fe-e76737163bfa"
"instanceHrid":"in00000000003"
"additionalInfo":
"suppressDiscovery":false
"state":"ACTUAL"
"leaderRecordStatus":"c"
"metadata":
"createdDate":"2021-05-06T19:02:03.338+0000"
"updatedDate":"2021-05-06T19:02:48.885+0000"
Questions that need updates/answers
...