Validation error with schema_version table name #1859
Closed
Milestone
Comments
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. |
axelfontaine
added a commit
to flyway/flywaydb.org
that referenced
this issue
Dec 8, 2017
dohrayme
pushed a commit
to dohrayme/flyway
that referenced
this issue
Feb 3, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: