While troubleshooting data migration script issues, I found myself looking for an easy way to verify these scripts without having to run a full blown FOLIO instance. Here's another option that requires only a database, and the ability to run the module under test locally.
This is essentially one-time setup you'll need to do.
First you'll need a database. Here's a how to setup postgres w/ docker:
Clone and build modules
Now that you have a database, clone the git repo using the appropriate branch/tag and build with maven
Run/Initialize the version you're upgrading from
Start the module up and hit the tenant API to initialize the database
Check that things are working
- via logging into the database and directly inspecting things
- making API calls to the module
- inspecting logs
- dump schemas for later comparison e.g.
pg_dump -hlocalhost -p5432 -Ufolio -dfolio -ntesttenant_mod_finance_storage -npublic > before.sql
Load additional data
This step is optional. If you want to add data to the system to exercise edge cases or see how things behave when migrating larger data sets, now is the time to do so.
- via API
- via directly loading them into the db, e.g.
Run the version you're upgrading to and perform the upgrade
Stop the old module before proceeding
Validate upgrade and data migrations
- Inspect logs. However, only doing that is usually not good enough.
- Test data-migration scripts are run successfully by query the data to make sure the changes were applied
- Via logging into the database and directly inspecting things that you expect to be added or changed
- Make sure the proper indexes are created by cross verify the new additions to schema.json with the indexes in the schema
- All the required functions and triggers if any are updated according to the latest release
- Dump schemas and compare to previous, e.g.
pg_dump -hlocalhost -p5432 -Ufolio -dfolio -ntesttenant_mod_finance_storage -npublic > after.sql; diff before.sql after.sql
- Making API calls to the module
- This can be tested on unreleased or snapshot versions of modules as well (e.g. HEAD of master, or even after making local changes), but keep in mind that the
module_toversion should align with the
fromModuleVersionproperty in your module's
- If you find a problem and want to fix and repeat you can either "drop cascade" the schema and role for you tenant/module, or you can specify a different value for X-Okapi-Tenant when making the calls to the tenant API.
- If you prefer, an alternative to building the current/old module from source is to pull/run the official docker container from dockerhub, e.g.
docker pull folioorg/mod-finance-storage:4.1.1
- Please help contribute here...