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
API: Make it possible to use pre-instantiated Java-based migrations #1062
Comments
Hi, |
@kapil-malik Thanks and yes this would be really useful. @axelfontaine Thanks a lot for taking it up as a feature! |
+1 for this! For those that cannot wait until this gets done: I have added a workaround on stackoverflow: http://stackoverflow.com/a/36474970/40064 BTW: If this is released, will there be an easy way to still have the SQL resolver as well to avoid the hacky workaround I had to do now? |
@wimdeblauwe Thank you very much! That was extremely helpful! |
+1, that would be a very useful feature. |
See also #869 |
+1 |
3 similar comments
+1 |
+1 |
+1 |
When I use Spring JPA flyway migrations seem to run before the application context has been instantiated ... Does anyone know of a way around this, or how I can instantiate my repositories inside a flyway migration? |
We use a workaround from https://github.com/avehlies/spring-beans-flyway2 But I really don't recommend injecting data repo in migrations since the domain could have been changed. |
Yes, I've tried that technique... But in my project, flyway migrations are being run before the application context - I get Null exceptions. |
Infact, if you take that project (spring-beans-flyway2) and add |
Sry I forgot to mention our configuration: @Configuration
class FlywayConfiguration {
@Primary
@Bean(name = "flywayInitializer")
@DependsOn("springUtility") //or whatever your ApplicationContextAware is named
FlywayMigrationInitializer flywayMigrationInitializer(){
//your flyway init configuration...
}
} The trick here is to force FlywayMigrationInitializer to get instantiated after the ApplicationContextAware workaround |
I will try that when I get home. Thanks so much. EDIT: I did eventually get this working. See my SO answer here. Thanks everyone. |
+1 |
1 similar comment
+1 |
+1, this should really get fixed at some point. |
Now I use my simple Migration for app, very simple. I leave https://github.com/purocean/kotlin-db-migration
Only support MySQL :( |
This has now been implemented generically using a new Spring users can use this to automatically use all import org.flywaydb.core.Flyway;
import org.flywaydb.core.api.migration.JavaMigration;
import org.springframework.context.ApplicationContext;
...
ApplicationContext applicationContext = ...; // obtain a reference to Spring's ApplicationContext.
Flyway flyway = Flyway.configure()
.dataSource(url, user, password)
// Add all Spring-instantiated JavaMigration beans
.javaMigrations(applicationContext.getBeansOfType(JavaMigration.class).values().toArray(new JavaMigration[0]))
.load();
flyway.migrate(); |
@axelfontaine Thanks for incorporating the feedback! I will have a look at it when I'll work again with a Spring project. Maybe someones else in the thread is able to use it the way you implemented it. Always nice to see that feedback gets integrated! |
@axelfontaine Thanks, |
…-based migrations
@simonzhong1985 Right now all of my Flyway config is handled through the application.yml. Can I still configure it that way when using your code - I'm referring to this comment: //your flyway init configuration... Also, I don't know what class the second snippet is in. This is the snippet where you get a reference to Spring's ApplicationContext and call flyway.migrate(). What calls this code? |
Has something changed since @axelfontaine's comment? It appears that having a JavaMigration as a Spring Component (and making use of dependency injection, etc) is automatically loaded and migrated without needing to define a |
As @jamesdh pointed out, we are able to use BaseJavaMigration as spring Once we upgraded to spring boot 2.7.4 however, we did have to set allow-circular-references=true to avoid circular dependency errors. I've been trying to find a way to preserve what we have, without setting allow-circular-references=true, as that seems to be framed as an option of last resort. I've yet to find a satisfactory solution. The command line runner strategy mentioned here allows the spring boot app to become accessible before the migrations are finished running, and has the added disadvantage of not being configurable via application.yml. I've been searching for a way to trigger the migration at a point where we'd avoid circular dependency issues, but prior to the application becoming available, but haven't found a solution yet. And the SpringUtility strategy mentioned here which would allow us to keep the application.yml based configuration, didn't resolve the circular dependency issues for us. We recognize that having migrations use repository/entity code is an issue when our object model changes. The strategy we employ is to simply remove the migration body once this becomes a problem, and to create a new migration, if it is behavior we need to preserve. We typically use java/spring based migrations for data seeding/migration tasks and not to create db structure. It'd be nice if the ability to use spring/java based migrations (making full use of the repository layer) was documented and fully supported in the future. Using JDBCTemplate is not a satisfactory solution for use, when we have a nice repository layer to work with. EDIT
|
Hi,
as we are using Spring with Flyway we want to use other beans inside the
SpringJdbcMigration
s. Therefore we created a new resolver which retrieves theSpringJdbcMigration
s from the Spring application context. This way we are able to define the migrations inside the application context and reference other beans we would need for this migration inside theSpringJdbcMigraiton
with the dependency injection mechanisms of Spring (@Autowired
). Please have a look at the linked pull request and the tests how this is done.If this pull request is accepted and integrated, then I would also add some documentation to the website project of Flyway on how to use this new resolver.
Thanks and regards,
Guy
The text was updated successfully, but these errors were encountered: