Skip to content
Snippets Groups Projects

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)

Edited by Liam Clark

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Liam Clark changed milestone to %Queue 1.0

    changed milestone to %Queue 1.0

  • Liam Clark added 1 deleted label

    added 1 deleted label

  • Liam Clark marked as a Work In Progress

    marked as a Work In Progress

  • Liam Clark changed the description

    changed the description

  • Author Contributor

    Changed to WIP because of problems with the automatic ddl creation of hibernate

  • Author Contributor

    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
  • Liam Clark added 1 commit

    added 1 commit

    • 283e81c1 - Include generated changelog for the existing database

    Compare with previous version

  • closed

  • Otto Visser mentioned in merge request !134 (merged)

    mentioned in merge request !134 (merged)

Please register or sign in to reply
Loading