We should re-enable liquibase or similar

[vjrj]

I see that liquibase was commented in:
https://github.com/AtlasOfLivingAustralia/spatial-service/releases/tag/1.1.2

If some new compatibility issue aroused, the plugin page in github gives some directions about which version we should use depending on grails and hibernate:
https://github.com/grails/grails-database-migration#versions

In the recent past this was not well documented and I suffer a bit to make it work with old versions of grails/hibernate/mysql-connector:
AtlasOfLivingAustralia/collectory#84 (comment)

In order to have a good maintenance of our dbs we should use some tool like liquibase or similar. For instance, disabling this, portals migrating directly to 1.1.2 will lose this db change:
https://github.com/AtlasOfLivingAustralia/spatial-service/blob/master/grails-app/migrations/changelog.xml
or similar.

cc @adam-collins

[adam-collins]

Supporting the 'or similar' through database change statements in BootStrap.groovy

[vjrj]

BTW liquibase also allows plain sql statements instead of a xml based changelogs, see:
https://github.com/AtlasOfLivingAustralia/collectory/blob/a9fc021b058ce4fcf3f30188c92154dd2e460bcb/db/changelog/changelog.xml#L18

Some liquibase (or flyway) advantages to plan db changes:

• automatically track which changes have been applied
• rollback of changes if something goes wrong
• not to code yourself the previous functionality
• something we use in others ALA modules

[adam-collins]

Grails was supposed to track changes without the need to rely on liquibase or flyway. Unsure why that was not working. Liquibase prevented the application from starting in our production environment and playing with the configuration did not fix it. Auto track was not implemented into the build. Rollback would be nice if something goes wrong.

All in all I spent less time to write these couple of lines of code than I had spent trying to work out why liquibase prevented the application from starting on our production.

[vjrj]

In grails to use an automatic database migration is not recommended, it's only for development purposes:
https://docs.grails.org/latest/guide/conf.html#automaticDatabaseMigration
this is flyway or liquibase are used.

If you point me to a branch and you show me the the couple of sql lines, I can help re-adding the liquibase support.

[adam-collins]

Is there a workaround because liquibase prevents the application from starting in our production environment. The removal of liqubase fixed the problem. jstack was used to identify the issue as liquibase. I'm not inclined to test it in our production environment.

[adam-collins]

I may have found the problem that was preventing the application from starting when using liquibase. I suspect it was an issue with an in-progress postgres backup. I will put this on hold until the postgres backup is updated, though this might take a while.

[vjrj]

Just for the record, for me, using Liquibase (or a similar tool) is as essential as using Git (or version control) in a project.

If helps: About postgresql backups, I use backupninja
https://manpages.ubuntu.com/manpages/jammy/man1/backupninja.1.html
(configured via ansible) to create daily backups of mysql/pg/mongo and these backups a copied too in the normal filesystem backup.