we’re have succesfully migrated our project from Cuba to Jmix 1.6. During the migration, we used our development-database to perform the migration on and this worked fine.
However, we have instances of our application running for many different customers, all with their own (currently cuba) database. Of course, alle these database are identical in terms of tables & rows, they al just contain different customerspecific data. How can we migrate all these databases whilst keeping the data? We found out that just starting the jmix-application and letting liquibase do it’s thing on the exisiting cuba-database does not seem to work, we get many errors about tables already exisiting…
Any pointers?
Are your dev database and production databases have the same structure?
If you have succeeded in migration you dev database with data then your migrated project is ready to be used to migrate production (dry-run on prod-like environment is recommended).
thnaks for you reply. Yes, our production and dev databases are identical. We investigated a bit further. We did three tests. Each time we first restored an ‘old’ production-database, filled with customer-data in cuba-format.
Test 1:
We used “main.liquibase.contexts=migrated” and started the application.
Result: Migration failed for change set io/jmix/securitydata/liquibase/changelog/003-security-data.xml, ERROR: relation “sec_user_substitution” already exists
Test 2:
We used “main.liquibase.contexts=cuba” and started the application.
Result: Migration failed for change set nl/xxxx/disthub/liquibase/changelog/2024/08/13-112925-76d17a98.xml: ERROR: relation “disthub_address” already exists.
This error I find strange. Of course this table already exists, it’s in our cuba-database, there is no need to recreate it.
Test 3:
We removed property “main.liquibase.contexts” and started the application.
Result: Same as test 1.
Solution:
What we finally did is add “context=”!cuba"" to every changeset in our changelog so liquibase would not complain about exisiting tables as long as main.liquibase.contexts=cuba, i.e.:
If you have the set of scripts to recreate database from scratch on Jmix (like it’s just a fresh Jmix application without CUBA “background”) then yes, those scripts should be marked with “!cuba” or “migrated” context to not be executed during migration of existing CUBA database.
Unfortunately it’s not automated. We will check what we can do (at least mention this in guide).
If you need to created some custom scripts to finalize migration (some fixes or tuning) - they should be marked with “cuba” context as well to be part of the migration.
Any following scripts created within further development should not be marked with any context so they will be executed in any case because they are based on the same single “starting point” - Jmix application (migrated or created from scratch).
And a little tip - you don’t have to mark every changeSet with context - you can mark the entire databaseChangeLog so all internal changeSets will be considered as marked.