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

Flyway multiple datasource migration does not work on native #7685

Closed
yanxuehe opened this issue Mar 9, 2020 · 5 comments · Fixed by #8065
Closed

Flyway multiple datasource migration does not work on native #7685

yanxuehe opened this issue Mar 9, 2020 · 5 comments · Fixed by #8065
Assignees
Milestone

Comments

@yanxuehe
Copy link

yanxuehe commented Mar 9, 2020

The below is the application.properties

it works on jdk 8.
not on graalvm 19.3.1
the error is

org.flywaydb.core.api.flywayexception: found more than one migration with version 1.0.0

if i change the sql files with different versions.
then all the sql files will be executed for all the data sources

quarkus.datasource.db1.driver=com.mysql.cj.jdbc.Driver
quarkus.datasource.db1.url=jdbc:mysql://mysql:3306/db1
quarkus.datasource.db1.username=user
quarkus.datasource.db1.password=p@ssw0rd
quarkus.datasource.db1.min-size=1
quarkus.datasource.db1.max-size=10

quarkus.datasource.db2.driver=com.mysql.cj.jdbc.Driver
quarkus.datasource.db2.url=jdbc:mysql://mysql:3306/db2
quarkus.datasource.db2.username=user
quarkus.datasource.db2.password=p@ssw0rd
quarkus.datasource.db2.min-size=1
quarkus.datasource.db2.max-size=10


quarkus.flyway.migrate-at-start=false

quarkus.flyway.db1.schemas=MyTracker_PATIENTS
quarkus.flyway.db1.locations=db/db1
quarkus.flyway.db1.migrate-at-start=true

quarkus.flyway.db2.schemas=db2
quarkus.flyway.db2.locations=db/db2
quarkus.flyway.db2.migrate-at-start=true
@gsmet gsmet added this to the 1.3.0.Final milestone Mar 9, 2020
@gsmet
Copy link
Member

gsmet commented Mar 9, 2020

Could you provide a small reproducer? Thanks!

@yanxuehe
Copy link
Author

yanxuehe commented Mar 9, 2020

Could you provide a small reproducer? Thanks!
plz refer this, thanks!
https://github.com/quarkus-reproducers/flyway-issue-7685

@gsmet
Copy link
Member

gsmet commented Mar 11, 2020

@machi1990 do you think you could have a look at that one?

@machi1990
Copy link
Member

@machi1990 do you think you could have a look at that one?

@gsmet I am just seeing the ping now. I'll have a look over the coming days.

@machi1990 machi1990 self-assigned this Mar 22, 2020
machi1990 added a commit to machi1990/quarkus that referenced this issue Mar 22, 2020
The QuarkusPathLocationScanner returned all migrations locations by default, this risked to cause
collision when we have a same filename for a migration script which is handled by different
datasources - a behaviour encountered on the issue quarkusio#7685. Let's avoid this case by making sure that
the scanner only returns migration that it can recognize.

Fixes quarkusio#7685
@machi1990
Copy link
Member

@machi1990 do you think you could have a look at that one?

@gsmet I am just seeing the ping now. I'll have a look over the coming days.

@gsmet I had a couple of hours with which I have opened #8065.

The PR once merged should fix the issue @yanxuehe

machi1990 added a commit to machi1990/quarkus that referenced this issue Mar 22, 2020
The QuarkusPathLocationScanner returned all migrations locations by default, this risked to cause
collision when we have a same filename for a migration script which is handled by different
datasources - a behaviour encountered on the issue quarkusio#7685. Let's avoid this case by making sure that
the scanner only returns migration that it can recognize.

Fixes quarkusio#7685
gsmet pushed a commit to gsmet/quarkus that referenced this issue Mar 24, 2020
The QuarkusPathLocationScanner returned all migrations locations by default, this risked to cause
collision when we have a same filename for a migration script which is handled by different
datasources - a behaviour encountered on the issue quarkusio#7685. Let's avoid this case by making sure that
the scanner only returns migration that it can recognize.

Fixes quarkusio#7685
viniciusfcf pushed a commit to viniciusfcf/quarkus-fork that referenced this issue Sep 7, 2020
The QuarkusPathLocationScanner returned all migrations locations by default, this risked to cause
collision when we have a same filename for a migration script which is handled by different
datasources - a behaviour encountered on the issue quarkusio#7685. Let's avoid this case by making sure that
the scanner only returns migration that it can recognize.

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

Successfully merging a pull request may close this issue.

3 participants