Context qualifier matches when no context available

General Discussion
1

Good evening.

I have this line in my master changelog:

<include context="master,prod" file="generate_credentials.sql"/>

If I pass a qualifier like --contexts=dev to the command line tool, the changeset does not run, as expected.

Therefore it seems entirely logical that if I don’t pass any --contexts= qualifier at all the changeset would also not run. However, that is not the case. Am I missing something?

Thanks,

/afb

1 Like
2

By default if you don’t specify a contexts= in your command line statement it will ignore all contexts tags. So it will basicly run all statements, independent of the context you declared.

So I think you should think if your use case is suited for using a context.

1 Like
3

Thanks, Frank. I understand that is what it is doing but it doesn’t seem like the optimal behavior as I would expect context to always be used as a limiting specified.

In any case, if the context is not the best option for our use case, is there another approach you would recommend? I didn’t see one.

1 Like
4

Hi @ablock, @frank.tubbing is right. From my perspective, context is limiting. If you don’t have any limiters, then liquibase is assuming there aren’t any.

How do you believe not specifying context in the commandline should work? If you want to limit, you could explicitly add what labels or context you are matching on.

5

@ronak I would expect that a changeset with a context would only run if that context was specified, so running liquibase without a context would only run changesets that similarly have no specified context.

1 Like
6

Hi @ablock,

Currently, context run this way:

Only changeset s marked with the passed contexts will be run.

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.

That’s how folks currently use Liquibase, but it is community driven software, you could put an issue in or create a PR to have it work differently but, I believe the direction was set this way b/c the most common case is to run everything and not set up context on EVERY changeset, but rather default to running the changeset.

To file and issue, and to see if others feel the same way you could do that here:

Or usually more weight is given to folks who feel strongly enough and have the ability to update LB directly, could write a PR:
https://github.com/liquibase/liquibase/pulls

Another option is, if you want changesets to NOT run, that you have already added a context to (ex. test), you can specifically say:
context=”!test”

Hope that helps,

Ronak

7

@ronak thanks for stating this so clearly. I was looking for that confirmation but to me the documentation doesn’t make it clear (enough).

@ablock these days things are maybe less confusing. In 4.16.0+, they moved to using the term “context filter” for changesets to distinguish from the runtime context argument (i.e. contextFilter="test" in changesets).
→ This is a Story about Control: context-filter, label-filter  | Liquibase.com