This really should have been done as part of the reworking of database initialization in 2.5 but unfortunately I missed it.
Comment From: wilkinsona
This is more complicated than I had expected.
We currently have DataSourceInitializationConfiguration
annotated with @ConditionalOnMissingBean(AbstractScriptDatabaseInitializer.class)
. To allow the initialisers for Batch, Integration, Quartz, and Session JDBC to use DataSourceScriptDatabaseInitializer
-based equivalents, they would have to be auto-configured after SqlInitializationAutoConfiguration
which imports DataSourceInitializationConfiguration
. So far so good.
Things get complicated due to the current Batch, Integration, Quartz, and Session JDBC initializers also being @ConditionalOnMissingBean
. If a user wants to take advantage of this and define their own initializer and that initializer is a DataSourceScriptDatabaseInitializer
, it'll cause the main initializer to back off which we don't want.
A few ideas:
- Drop the
@ConditionalOnMissingBean(AbstractScriptDatabaseInitializer.class)
fromDataSourceInitializationConfiguration
. It can still be disabled by settingspring.sql.init.mode=never
. This feels rather inconsistent with the rest of Boot. - Don't use
DataSourceScriptDatabaseInitializer
beans to initialize the Batch, Integration, Quartz, and Session schemas. This is effectively what we have today. - Drop support for users defining their own Batch, Integration, Quartz, and Session JDBC initializers
- Formally introduce the concept of an additional database initializer and use the
ignored
attribute on@ConditionalOnMissingBean
to prevent such an initializer from causingDataSourceInitializationConfiguration
to back off.
At the moment, 2 or 4 feel the least bad to me. There is something of a conceptual difference with the Batch, Integration, Quartz, and Session JDBC initializers as they're supposed to be complementary to each other and to be performed in addition to the general script-based initialization.