FOLIO has two types of data: Reference and Sample. Reference data is most similar to "configuration" (loan rules, permissions, item status) and sample data is most similar to "content" (instances, holdings, items). Reference data may be controlled entirely by code, both in code and by users, or only by users; may be changed by code during upgrades (replacing deleted values or creating an error if a new unique key conflicts with a user created value).
The FOLIO project is working on better ways to handle reference data during upgrades (see Resources). We need to define a process to move Reference Data between to identical instances of FOLIO. This will help us create/rec-create instances for data migration and testing.
[ ] Runs in a container inside the cluster
[ ] Can run export and import independently
[ ] Can store data in S3 (not sure how this might impact the ability to manually edit the data, which would be nice to do)
I has been mentioned that some data like Import Profiles and eHoldings KB config are not migratable via APIs and need do be done by syncing database tables.
FOLIO has two types of data: Reference and Sample. Reference data is most similar to "configuration" (loan rules, permissions, item status) and sample data is most similar to "content" (instances, holdings, items). Reference data may be controlled entirely by code, both in code and by users, or only by users; may be changed by code during upgrades (replacing deleted values or creating an error if a new unique key conflicts with a user created value).
The FOLIO project is working on better ways to handle reference data during upgrades (see Resources). We need to define a process to move Reference Data between to identical instances of FOLIO. This will help us create/rec-create instances for data migration and testing.
Resources
Code samples