Now when I run a regular update command without specifying a context, the table is still created.
My understanding was, that when I do not specify a context, all changeset without a context are executed and those that have a context are not executed. Is this understanding wrong?
How can I ensure that this changeset is only executed when I do specify a context?
I don’t know if it is a bug, but it is sure counterintuitive. You specify a context name that you know does not exist, like dummy, or fred, or any string you make up.
I just found this post. We have the same issue (Earlier today I posted this related message). Specifying a context to run all those changesets that have no explicit context is no option in our case. IMO this is a conceptual bug that should be fixed.
I’m afraid that’s no possible in our scenario (and should not be necessary). The (context-less) changesets must be executed by our users in production.
I’ll let Liquibase comment on whether they think is a conceptual bug or not, but the functionality is documented, so I would say it’s not a bug, it’s just a different way to approach it than you would like:
“If you don’t assign a context to a changeset, it will run all the time, regardless of what contexts you pass in to the migrator. If you do not specify a context when you run the migrator, all contexts will be run.”
The tables will be the same both in testing and in production environment. But preconditions might be the way to go nonetheless. I am currently evaluating writing a custom precondition.
Not sure what dbms you are using, but in Oracle I would query something like v$instance and it will provide environment-specific data, not the same in test and prod.