You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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
methodexists()
.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:
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.The text was updated successfully, but these errors were encountered: