I'm using Liquibase 3.3.5 to update my database. Having contexts is a nice way to only execute specific parts of the changelog. But I don't understand, why ALL changesets are executed, when no context is provided on update. Consider the following example:
So
For me, this doesn't make sense at all :).
I would expect, that only changeset B will be executed, since it doesn't define a specific context.
In the Liquibase contexts example: http://www.liquibase.org/documentation/contexts.html ("Using Contexts for Test Data") they say, that one should mark the changesets for testing with "test", and executing them with giving the context "test" to apply testdata. Fine - make sense. But
"When it comes time to migrate your production database, don’t include the “test" context, and your test data not be included. "
So, if I wouldn't specify "test" context when executing production update, it would execute the "test" changesets as well, since I didn't specify a context at all.
Again, I would expect that leaving out test on update execution, would only perform the regular changesets without the test changesets.
Or I'm missing something here :)?
Contexts in Liquibase are expressions you can add to changesets to control which changesets will be executed in any particular migration run. Context names are case-insensitive strings. When you run the migrator though any of the available methods, you can specify a set of contexts to run in the CLI.
The runOnChange changeset attribute runs the change the first time it is detected and each time the changeset is modified. Liquibase determines that a changeset has been modified by comparing the MD5 checksum for the changeset to the checksum stored in the DATABASECHANGELOG table.
Labels are tags that you can add to changesets to control which changeset will be executed in any migration run. Labels control whether a changeset is executed depending on runtime settings.
This is just how Liquibase works - if you do an update and don't specify a context, then all changesets are considered as applicable to that update operation.
There were a couple of ways that this could have been implemented, and the development team had to pick one.
The team could have gone with option 3 (which matches your expectation) but decided long ago to go with option 2, as that seemed like the 'best' way at the time. I wasn't on the team at that time, so I don't know any more than that.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With