WIP: Liquibase database migration setup
This mr sets up liquibase to run when spring boots, which is convenient for development. However for production running the liquibase-cli through ansible might be a nicer alternative. @otto what do you think?
I currently chose the yaml format, because it is less verbose than the xml. It is however less documented than the xml format, we can perhaps discuss what format we want to pick in #199 (closed).
Lastly @otto do you want this as a change on it's own or should I create an mr regarding #197 (closed) building on this mr and merge those as an atomic change?
The template properties file contains settings to run the liquibase migrations through spring, when spring starts.
There is a sample dummy changelog included in: main/resources/changeLog.yaml
Closes #199 (closed)
Merge request reports
Activity
changed milestone to %Queue 1.0
Essentially the problem is that liquibase runs before the hibernate schema creation, so the changing of the table crashes and then hibernate never runs so the schema never gets created.
The work around currently woudl be remove the liquibase dependency, run the queue to generate the schema. Quit the application re-enable liquibase and migrate the schema. which well sucks.
The documentation here says:
Make it look like you’ve always been using Liquibase The goal of this approach is to have a changelog file that matches the current state of your database. You can run this changeLog against a blank database and the final result will be indistinguishable from your existing databases–as if you used Liquibase from the beginning. This approach is usually the best long term, but it can be more work up front. Create ChangeLog Creating the changelog to match your database can be done automatically using the generateChangeLog command or be done manually. For any database larger than a few tables, the generateChangeLog command is usually a good idea but make sure you go through the generated changeSets to ensure they are correct. Liquibase does not always detect more complex structures like stored procedures or details like if an index is not clustered. Also, ensure data types are as you expected them.
Which I will do tomorrow and update this mr
- I'd say yaml is nicer to read/write; but if some of these migrations are created automagically because of adding a class it matters less
- #197 (closed) probably should depend on #199 (closed) and gitlab state should preferably reflect that
- for deployment I see a few options; via gitlab as a deploy stage or otherwise via ansible
added 1 commit
- 283e81c1 - Include generated changelog for the existing database
mentioned in merge request !134 (merged)