ChangeSet with context executied even though no context was specified

General Discussion
1

Hi,

I have a changeSet that looks like this:

  2.    
  3.         …
  4.    
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?

Thanks
Thomas
 


2

But how do I run those changeSets then which do not have a context?

This does sound like a bug to me.

3

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.


Best,

Laird

–
http://about.me/lairdnelson

4

Try by specifying always a context.

5

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.

6

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.

7

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.”

https://docs.liquibase.com/concepts/advanced/contexts.html

8

Yes, we know it’s documented. That’s why we are trying to find an alternative solution. The execution context is not usable for us, unfortunately.

9

How about adding a changeset precondition, where you check a table in your database to determine what environment you are in?

10

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.

Thanks again for your input! :slight_smile:

1 Like
11

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.

12

We need to be able to use a few different DBMS (PostgreSQL, MariaDB, Oracle, …).

13

FYI: The custom precondition way works and looks good. All the custom class does is check if a certain Java system property is set to “true”. :sunglasses:

1 Like