The flyway auto-configuration in Spring Boot has the very nice feature of replacing {vendor} in any spring.flyway.locations path with database-specific values to support multiple databases easily.
The code for those replacements is in FlywayAutoConfiguration.LocationResolver: https://github.com/spring-projects/spring-boot/blob/70a5dc64f6b4160ec9c20d48d84a0869ef735df8/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration.java#L361
On the other hand, we have the convenient @Sql annotation to run SQL scripts before tests are running. It would be very nice, if {vendor} could also be part of those paths given to Sql.scripts with the same replacement logic as flyway.
I have a specific use case for that: Currently, we have two systems in place at our company (a shared library and a dedicated application) that are built to run on multiple database systems (Postgres, MySQL, MariaDB, and HsqlDB). We have set up maven, such that some tests are run multiple times with different databases in test containers using multiple maven-surefire-plugin executions. It would be great if I could still make use of the @Sql annotation in that case with the vendor replacement.
Comment From: sbrannen
Hi @kistlers,
Congratulations on submitting your first issue for the Spring Framework! 👍
That's an interesting idea.
Unfortunately, the {vendor} feature of Spring Boot's Flyway support is based on Spring Boot's DatabaseDriver enum which is specific to Spring Boot.
Thus, we cannot rely on that within the spring-test module.
In addition, we do not intend to introduce any comparable functionality within the core Spring Framework.
Instead, we recommend the use of bean definition profiles for controlling which DataSource to use for a given test suite, and you can associate properties with such profiles.
The only piece of the puzzle missing is the ability to use property placeholders (${...}) within the script paths you supply to @Sql.
In light of that, I've decided to repurpose this issue to address that shortcoming.
You can view a proof of concept here: https://github.com/spring-projects/spring-framework/compare/main...sbrannen:spring-framework:issues/gh-33114-placeholders-in-Sql-script-paths
There you can see a "classpath:org/springframework/test/context/jdbc/${vendor}/data.sql" @Sql script location which uses a ${vendor} property placeholder analogous to the {vendor} placeholder you proposed.
Comment From: kistlers
Thanks, that works for me!