I am migrating an old project to a new setup. It is still on Liquibase 1.8 and that did not work anymore. Anyway, upgrading to Liquibase 4.23 kind of worked alright, but no changes are applied in the end.

The dependency is

<dependency>
    <groupId>org.liquibase</groupId>
    <artifactId>liquibase-core</artifactId>
    <version>4.23.0</version>
</dependency>

The project uses liquibase programmatically at startup like so:

DataSource ds = ...
try (
    Connection c = ds.getConnection();
    Liquibase lb = new Liquibase(changelog, new DirectoryResourceAccessor(root), new JdbcConnection(c))
) {
    // need to check, if we need to fix/upgrade schema tables!
    lb.checkLiquibaseTables(false, lb.getDatabaseChangeLog(), new Contexts(contexts), new LabelExpression());
    // and migrate!
    OutputStreamWriter output = new OutputStreamWriter(System.err);
    lb.update(contexts, output);
}

Based on configuration the same migration may be performed for different databases.

I see that the DATABASECHANGELOG table and the DATABASECHANGELOGLOCK are created.

For all other changes, liquibase is only logging the statement.

By debugging I found that when trying to execute a ChangeSet and when looking for the "jdbc" executor it actually gets a LoggingExecutor that was put there (silently) by an OutputWriterCommandStep that for reasons I do not understand ended up in the command pipeline.

Any suggestion how to avoid this and getting the actualy JdbcExecutor would be really helpful.

Thanks!

I am migrating an old project to a new setup. It is still on Liquibase 1.8 and that did not work anymore. Anyway, upgrading to Liquibase 4.23 kind of worked alright, but no changes are applied in the end.

The dependency is

<dependency>
    <groupId>org.liquibase</groupId>
    <artifactId>liquibase-core</artifactId>
    <version>4.23.0</version>
</dependency>

The project uses liquibase programmatically at startup like so:

DataSource ds = ...
try (
    Connection c = ds.getConnection();
    Liquibase lb = new Liquibase(changelog, new DirectoryResourceAccessor(root), new JdbcConnection(c))
) {
    // need to check, if we need to fix/upgrade schema tables!
    lb.checkLiquibaseTables(false, lb.getDatabaseChangeLog(), new Contexts(contexts), new LabelExpression());
    // and migrate!
    OutputStreamWriter output = new OutputStreamWriter(System.err);
    lb.update(contexts, output);
}

Based on configuration the same migration may be performed for different databases.

I see that the DATABASECHANGELOG table and the DATABASECHANGELOGLOCK are created.

For all other changes, liquibase is only logging the statement.

By debugging I found that when trying to execute a ChangeSet and when looking for the "jdbc" executor it actually gets a LoggingExecutor that was put there (silently) by an OutputWriterCommandStep that for reasons I do not understand ended up in the command pipeline.

Any suggestion how to avoid this and getting the actualy JdbcExecutor would be really helpful.

Thanks!

• liquibase

1 Answer 1

To answer my own question: I found that using the (deprecated):

lb.update(new Contexts(contexts), new LabelExpression(), true);

the behaviour is different and changes are applied. I do not fully understand why and I spent too much time debugging the abstractions of Liquibase already to still care.

Now with 4.23 it does not accept the old checksums and with 4.21 it reruns 1.8 changelogs leading to errors. That is particularly "funny" for a migration tool.

I am giving up and will port to the tool we switched to a long time ago.