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

USE sql command leaks to subsequent migration files #1764

Closed
CMCDragonkai opened this issue Sep 7, 2017 · 3 comments
Closed

USE sql command leaks to subsequent migration files #1764

CMCDragonkai opened this issue Sep 7, 2017 · 3 comments
Labels
Milestone

Comments

@CMCDragonkai
Copy link

@CMCDragonkai CMCDragonkai commented Sep 7, 2017

What version of Flyway are you using?

Flyway 4.2.0

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

Commandline

What database are you using (type & version)?

MySQL 5.7

What operating system are you using?

Linux

What did you do?

I have sql migration files. Inside one of them I wrote USE db. I then ran flyway migrate.

What did you expect to see?

I expected that each migration would be it's own independent transactional session. I did not expect that USE db in one SQL file would leak to affect other SQL files. This would mean possibly things like SET commands would also leak.

What did you see instead?

The USE db caused all subsequent SQL files to fail due to running on the wrong database.


The isolation of each sql file migration makes it easier to integrate generated sql files like from mysql_tzinfo_to_sql, which generates a sql file that needs to run against the mysql database. I had hoped that prepending USE mysql; would be good enough.

@axelfontaine axelfontaine added this to the Flyway 5.0.0 milestone Sep 7, 2017
@axelfontaine axelfontaine added the t: bug label Sep 7, 2017
axelfontaine added a commit to flyway/flywaydb.org that referenced this issue Nov 15, 2017
@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Nov 15, 2017

Thanks for reporting. Fixed!

@CMCDragonkai
Copy link
Author

@CMCDragonkai CMCDragonkai commented Nov 15, 2017

Does the fix also isolate other side-effectful statements like SET?

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Nov 15, 2017

It currently only ensures the current schema is reset correctly. Which statements specifically are impacting you?

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

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.