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

Database migrations may not have run before JdbcTemplate is used #13155

Closed
MatanRubin opened this issue May 13, 2018 · 11 comments
Closed

Database migrations may not have run before JdbcTemplate is used #13155

MatanRubin opened this issue May 13, 2018 · 11 comments
Assignees
Labels
type: bug A general bug
Milestone

Comments

@MatanRubin
Copy link

Using Spring Boot 2.0.2.RELEASE I set up a simple project that uses Flyway for migrations and JDBC template for accessing the DB. I expect all Flyway migrations to finish running before I can use the datasource. However, I noticed that PostConstruct runs before Flyway migrations. That means I access the old version of the schema, causing application failures.

As mentioned here, one may annotate the component that uses JdbcTemplate with: @DependsOn({"flyway", "flywayInitializer"}), but this is cumbersome and error prone - it is easy to forget to do so, and I don't see a reason this shouldn't be the default behaviour.

The attached project is a minimal Spring Boot application with a single component that uses the database in its PostConstruct method. The output shows that PostConstruct is called before Flyway runs.

demo-4.zip

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label May 13, 2018
@MatanRubin
Copy link
Author

Furthermore, even if I change the PostConstruct method to an EventListener that handles onApplicationReady events, the same behaviour persists. Unless I'm missing something, Flyway should definitely finish running before an ApplicationReady event happens. What am I missing?

@snicoll
Copy link
Member

snicoll commented May 14, 2018

What am I missing?

I don't know but it definitely runs as part of the InitializingBean callback (i.e. before that event is triggered).

As for your initial request, I think what we have right now is consistent with many other features. If you use @Transactional for instance, you can't use them as part of the @PostConstruct callback and you should use TransactionTemplate. Same things for caching. See also this section in the Spring Framework ref guide. Using the event is the right way of doing this (or you may way want to implement SmartInitializingSingleton).

Can you please share a sample that demonstrates that Flyway is not called when that event is fired?

@snicoll snicoll added the status: waiting-for-feedback We need additional information before we can continue label May 14, 2018
@MatanRubin
Copy link
Author

Please ignore my comment regarding onApplicationReady - I checked it again and it works well.

Regarding @PostConstruct, I disagree that this is consistent behaviour. Developers expect that once a bean is initialized, all its dependent beans are initialized. Flyway is not a piece of application code - it is an infrastructure tool that helps initialize the database - I don't see a use case where you want to use the old schema version in a @PostConstruct and then have Flyway run and change your schema.

@snicoll
Copy link
Member

snicoll commented May 14, 2018

I disagree that this is consistent behaviour.

That's not what I wrote. Please look at the link and the explanation again.

Developers expect that once a bean is initialized, all its dependent beans are initialized.

You don't have a dependency on Flyway, you have a dependency on a DataSource. I agree that it would be nicer if that was taken care for you. We have a similar request for another component and I think we could use that work to fix this problem as well.

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels May 14, 2018
@snicoll snicoll added type: enhancement A general enhancement and removed status: feedback-provided Feedback has been provided status: waiting-for-triage An issue we've not yet triaged labels May 14, 2018
@wilkinsona
Copy link
Member

This feels like a bug to me. If you consume the auto-configured JdbcTemplate (as is being done here), I think it's reasonable to expect that the underlying DataSource will have been initialized before you're given a chance to use the template. This situation is analogous to doing something with JPA. In that case we do ensure that any Flyway migrations have occurred before you can do anything with the database.

@wilkinsona wilkinsona added type: bug A general bug and removed type: enhancement A general enhancement labels May 14, 2018
@nameof
Copy link

nameof commented Jul 9, 2018

I have also been confused about this. If this is consistent with other features, please provide at least the corresponding instructions in the spring boot documentation.

@wilkinsona
Copy link
Member

@nameof Please read my comment that is immeadiately before yours. It’s a bug that we intend to fix.

@wilkinsona wilkinsona added this to the 2.0.x milestone Jul 9, 2018
@nameof
Copy link

nameof commented Jul 9, 2018

@wilkinsona got it , really sorry for this

@snicoll snicoll changed the title Flyway migrations run after @PostContruct of bean that uses the datasource Make sure JdbcTemplate is available once database migrations have occured Jul 10, 2018
@snicoll snicoll self-assigned this Jul 10, 2018
@snicoll snicoll changed the title Make sure JdbcTemplate is available once database migrations have occured Fix dependency order between JdbcTemplate and database migration tools Jul 11, 2018
@snicoll snicoll modified the milestones: 2.0.x, 2.0.4 Jul 11, 2018
@wilkinsona wilkinsona changed the title Fix dependency order between JdbcTemplate and database migration tools Database migrations may not have run before JdbcTemplate is used Jul 11, 2018
@jordanms
Copy link

We have the same problem with 2.2.4.RELEASE. Wasn't this supposed to be fixed?

@philwebb
Copy link
Member

@jordanms This issue should have been fixed for quite some time. If you're facing a similar problem, please open a new issue and provide a small sample application that demonstrates it.

@jordanms
Copy link

@philwebb I created the new issue with sample code: #21436

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A general bug
Projects
None yet
Development

No branches or pull requests

7 participants