Currently, the @Sql annotation in Spring supports specifying a single SQL script file using the value attribute. However, there is no support for specifying multiple files using wildcards or regex patterns.
To address this limitation, I propose adding path matching functionality to the value attribute of the Sql annotation. This would allow users to specify multiple SQL script files using a single value attribute by providing a file path pattern.
For example, users could specify all SQL script files in a directory using a wildcard pattern like "classpath:scripts/*.sql"。
I plan to implement this feature by extending the existing functionality of the SqlScriptsTestExecutionListener class. Specifically, I will modify the SqlScriptsTestExecutionListener to parse the value attribute of the @Sql annotation and use it to locate and execute the specified SQL script files.
I believe that this feature will improve the usability of the @Sql annotation in Spring and make it easier for users to manage their SQL script files in tests.
Please let me know if you have any feedback or concerns about this proposed change.
Thank you for your time and consideration.
Comment From: ShenFeng312
Could you give me some feedback on the PR or issue? @sbrannen
Comment From: sbrannen
Hi @ShenFeng312,
Thanks for raising the issue, and sorry for the belated reply.
I believe that this feature will improve the usability of the @Sql annotation in Spring and make it easier for users to manage their SQL script files in tests.
After internal discussions, the team has decided that we believe this feature could actually make it more difficult to use @Sql effectively.
@Sql has never supported wildcard pattern matching for script resources, because script execution order is often important if not essential: it is often required that DDL scripts execute before DML scripts. For example, you often need to create tables before populating them.
Even if you only have a bunch of DML scripts in a given folder, the order can still matter due to dependencies between tables, etc.
It may be possible to organize scripts into specially named folders and combine that with specially crafted wildcard patterns; however, we feel that doing so is likely more trouble than it's worth.
Looking at this from another angle, once you get to the point where you have multiple scripts that need to be imported using wildcard patterns, you are likely better off using a tool dedicated to that purpose, with explicit semantics for the order in which scripts are applied -- for example, Flyway, Liquibase, etc.
As a side note, the semantics of @Sql are analogous to those of @PropertySource (where order also matters), and the Javadoc for the value attribute in @PropertySource states the following.
Resource location wildcards (e.g.
**/*.properties) are not permitted; each location must evaluate to exactly one resource.
In light of that, we do not plan to introduce wildcard support for @Sql resource locations.