One connection is used for all migrations causes an issue with session params redefined #1250
What version of Flyway are you using?
What database are you using (type & version)?
What operating system are you using?
What did you do?
(Please include the content causing the issue, any relevant configuration settings, and the command you ran)
We have script1.sql and script2.sql and perform migrate:
We migrate scripts using Flyway API from Java.
Need to say I understand the gains behind opening connection only once (it may speed up things).
It's ok to have current behavior but would be nice to have connection management configurable: so we have an option to have connections to be opened/closed for everything migration.
What did you expect to see?
Result is the same no matter how often we run Flyway.
As we migrate scripts using Flyway API from Java then probably we should use Flyway Callbacks somehow to handle this case and reset session values by ourselves. Please advise.
What did you see instead?
One connection is opened and is used for all migrations. Some migrations affect other migrations
The text was updated successfully, but these errors were encountered:
Thanks. Your best bet at the moment is indeed to use a beforeEachMigrate callback to ensure the state of the connection is properly reset. Alternatively you can also make sure individual migrations don't have side effects.
I am not sure yet, whether it makes sense to fix this or not as Flyway is often used with connection pools. Also people use the callbacks to achieve exactly the opposite: set the one connection to a well-known state.
All in all this is a behavior change that would probably have to wait until at least the next major release.
Firs of all thank you for quick response and detailed explanation.
Could you please explain.
We are also searching for the best solution and in our case seems beforeEachMigrate callback suits the best where I thought we needed to create connection.prepareteStatement(...) to call sql script that set some values to default. But seems you have better idea.
That's why first thought was about moving it to parameters so default behavior would stay the same for back compatibility.