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:

  1. Drop the @ConditionalOnMissingBean(AbstractScriptDatabaseInitializer.class) from DataSourceInitializationConfiguration. It can still be disabled by setting spring.sql.init.mode=never. This feels rather inconsistent with the rest of Boot.
  2. Don't use DataSourceScriptDatabaseInitializer beans to initialize the Batch, Integration, Quartz, and Session schemas. This is effectively what we have today.
  3. Drop support for users defining their own Batch, Integration, Quartz, and Session JDBC initializers
  4. Formally introduce the concept of an additional database initializer and use the ignored attribute on @ConditionalOnMissingBean to prevent such an initializer from causing DataSourceInitializationConfiguration 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.