Question/Assumption | Response |
|
---|
I am unsure how this approach helps the following scenario: a library migrating authority records from one system to FOLIO | The library staff will have to export all MARC records for Authorities from the legacy system into the file(s) and feed those file(s) to the new module we will create. The rest will be done automatically. |
|
I see how it helps with the mapping rules situation | Yes, this is the simplest case |
|
Based on Slava and Pavlo's presentations, I am unclear how this will work in a cluster environment with multiple tenants. What happens when a hosting provider is upgrading one library from one release to another? What happens when hosting provider is upgrading multiple tenants on the same cluster? What happens when a library is added to the cluster, and we need to migrate records to FOLIO? | These main operations (reading data + mapping and reading from a file + saving directly into a database) are quite cheap in terms of consumed resources. So we can run this simultaneously for several tenants. If needed we can spin up more instances for mod-inventory-storage and mod-source-record-storage. The only requirement is that we can’t run more than one operation in parallel for the same tenant, and this operation should not intersect with a data import operation for the same tenant. |
|
What is the impact of this approach to consortia setup? | This is a good point, we need to investigate the impact of the shared MARC/Authority records on this solution. |
|
What happens when this process is run and there are data import jobs also running? | As stated above we can’t run this process and data import jobs (those that change Authority records) simultaneously for the same tenant. |
|
Lastly, I think we should have this approach and POCs reviewed by a hosting team. | I completely agree, we must ask for the review a hosting team. |
|