Liquibase FAQ

Why didn’t you create a baseline liquibase changeset so that we would not have to apply the foundation schema scripts outside of Liquibase?

• Short answer, it’s not practical, can possibly take my whole sprint time, and is too prone to error.
• Long answer, Liquibase uses third-party drivers like JDBC. The latest postgresql JDBC driver is 9.4. Now, there is a feature to “automagically” generate a base changelog — but as with all scaffolding technologies, it’s not perfect. So chances are, with the JDBC driver not having the latest postgresql features (9.5), we’ll need to do this by hand. But that doesn’t end there. We’ll need to test each and every part of it and make sure everything’s similar to the base sql version of it. Also, functions and other database objects are not supported by the scaffold.

I’m not sure how I feel about the “contexts” things? It seems to me that if you had only one context, our normal source control mechanism would take care of the DEV/TEST/PROD distinction: you would simply run the scripts on that branch and, by definition, they would put you at the dev/test/prod level of that branch.

• It allows us to have different migration paths. I may also be working on changes that I would want to give to Lynn but not to the GOBII system yet (as it may break other parts of the system). It allows for great flexibility and enables us to experiment. Think of it as feature branches in git. In the future, I may see test and dev as being redundant so I may just remove the test and keep the dev context. I will know after I use this in the db changes I have for this sprint. Besides, if you just run the default (with the property file set to ‘dev’), you’ll still get the latest updates. It may just be the case that in the middle of development, they require us to deploy (as you mentioned earlier today) — then it will be as simple as setting the property's context to ‘Test’ then running liquibase and you have a database ready for testing.
• Also note that the DB migration paths don’t always align with the feature being developed. In one feature branch, I may have a set of changesets that build the database with the structural changes required (context=dev), and another set of changesets that put in dummy data, indices, or even temporary views (context=dev and test).
• Also look at the ‘dummy’ context, I will be doing a lot of trial and error and will set the context to dummy — that in itself will be tracked in git, but those changesets will not and should not be used outside an experimental database instance.
• We are not, by the way, limited to the contexts I listed out. It can also be used for seed data and complex preconditions. Ex. Context = “prod and IRRI”