Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validation error with schema_version table name #1859

Closed
mdewilde opened this issue Dec 7, 2017 · 1 comment
Closed

Validation error with schema_version table name #1859

mdewilde opened this issue Dec 7, 2017 · 1 comment

Comments

@mdewilde
Copy link

mdewilde commented Dec 7, 2017

What version of Flyway are you using?

5.0.1

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin, SBT plugin, ANT tasks)

Java API

What database are you using (type & version)?

MySQL 5.5.57

What operating system are you using?

Windows 10

What did you do?

(Please include the content causing the issue, any relevant configuration settings, and the command you ran)
flyway.migrate();

What did you expect to see?

normal execution

What did you see instead?
org.flywaydb.core.internal.exception.FlywaySqlException: 
Error while retrieving the list of applied migrations from Schema History table `db`.`schema_version`
------------------------------------------------------------------------------------------------------
SQL State  : 42S22
Error Code : 1054
Message    : Unknown column 'installed_rank' in 'field list'

The problem is this: we were not using Flyway previously, and had our own custom schema_version table with our own (non-Flyway) version information.

In version 4.12.0, it was possible to simply use

Flyway.setTable("flyway_meta_table");

Doing so would leave our old own schema_version table untouched, and guide Flyway to use that other table.

Using the same setup with Flyway 5 no longer works. The issue is in org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory method exists().

It seems that the use of a custom table name is either not fully considered, or that Flyway now simply disallows having a table with name schema_version that it did not create.

I would suggest adding a check along the following lines:


    @Override
    public boolean exists() {
        if (!tableFallback && !isCustomTable()) {
            Table fallbackTable = table.getSchema().getTable("schema_version");
            if (fallbackTable.exists()) {
                LOG.warn("Could not find schema history table " + table + ", but found " + fallbackTable + " instead." +
                        " You are seeing this message because Flyway changed its default for flyway.table in" +
                        " version 5.0.0 to flyway_schema_history and you are still relying on the old default (schema_version)." +
                        " Set flyway.table=schema_version in your configuration to fix this." +
                        " This fallback mechanism will be removed in Flyway 6.0.0.");
                tableFallback = true;
                table = fallbackTable;
            }
        }
        return table.exists();
    }

    private boolean isCustomTable() {
        return !table.getName().equals("flyway_schema_history") && !table.getName().equals("schema_version");
    }

Ideally, it'd be nice to use String constants in the isCustomTable() check, but I haven't checked where such a constant might have been declared.

For our use, removing our schema_version table is not an option, so we'll stick with 4.12 for now.

@axelfontaine
Copy link
Contributor

Arggghh just when I thought we had considered all options! Nice catch, we really didn't think of this. Consider it fixed in the next patch release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants