Separate auto-configuration of script-based DataSource initialization from the auto-configuration of the DataSource

[wilkinsona]

Currently, the auto-configuration of script-based DataSource initialization is intermingled with the auto-configuration of the DataSource itself. This means that the spring.datasource.* properties are a mixture of those that are used to create the DataSource and those that are then used to initialise it using DDL and DML scripts. We should separate out the auto-configuration and the properties that are specific to our script-based initialization.

In addition to making it clearer which properties are for initialization and which are for general data source configuration, this will align the structure of the auto-configuration for our script-based initialization with how things are structured for Flyway and Liquibase.

[wilkinsona]

This issue is noteworthy as all of the spring.datasource properties that are specific to initialization are being deprecated with spring.sql.init replacements. The separate usernames and passwords for schema and data scripts are not being replaced. Instead, the same credentials, configured using spring.sql.init.username and spring.sql.init.password, are used for DDL (schema) and DML (data) scripts. If users need separate credentials for DDL and DML, they can define their own, appropriately configured data source initializer beans.

[wilkinsona]

Re-opening to include SqlInitializationAutoConfiguration in test slices that use JDBC.

[mmatela]

Am I missing something, or does this change make things more complicated for a pretty common scenario?
In our standard configuration the app connects to a postgresql server, so I need to set spring.sql.init.enabled=false so it doesn't try to create tables that already exist.
But now for tests we use @AutoConfigureTestDatabase so that an embedded database is used and the tests fail because the database is empty.
So I would need to change the configuration depending on whether I'm starting the app normally or just running tests. There was no such issue previously.
A workaround for now is to use the deprecated spring.datasource.initialization-mode = embedded, I hope it's not removed any time soon.

Or maybe the @AutoConfigureTestDatabase feature should be changed to force spring.sql.init.enabled=true?

[philwebb]

@mmatela You might want to follow #26682. Another option would be to move your .sql files to src/test/resources rather than src/main/resources.