This allows a custom URL to specified in @AutoConfigureTestDatabase.

It was not straightforward:

We leverage org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseBuilder in org.springframework.boot.test.autoconfigure.jdbc.TestDatabaseAutoConfiguration which ultimately delegates to 

org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseFactory 
-> 
org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseConfigurer#configureConnectionProperties

which in turn each configurer impl has the hardcoded URL it uses and sets the properties on the datasource. It is these configurers that have the last say in what the url is.

The EmbeddedDatabaseBuilder does not expose a setter for its EmbeddedDatabaseFactory so getting a "custom url respecting" configurer in this call chain is not straightforward and may not be possible w/o modification to Spring Framework EmbeddedDatabaseBuilder. Those configurers are all package protected as well so copying some code was not an option either.

Another note:

The hardcoding is in multiple places, the EmbeddedDatabaseConnection and in EmbeddedDatabaseConfigurer impls. For the purposes of this change I believe its fine just modifying the latter as the former is not used by any test code AFAICT.

Comment From: onobc

@snicoll

Instead of replacing the url entirely, I renamed the attribute to urlOptions and if specified it will then replace the options on the connection url string.

Example:

jdbc:h2:mem:7a5cf237-9160-40ba-b633-fda0ede74341;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=false

with urlOptions=MODE=MySQL will result in 

jdbc:h2:mem:7a5cf237-9160-40ba-b633-fda0ede74341;MODE=MySQL

This will allow the connection attribute to drive the base url and allow the user to override the connection options. I realize it may be nicer to override/append rather than replace but that got messy quickly. If you feel strongly about it I can add that back in. Otherwise, if the user is specifying any urlOptions they need to specify all of them. I think this is a fair tradeoff.

Comment From: onobc

Just pinging this one - I am guessing the team is just busy.

Comment From: philwebb

See #19038

Comment From: snicoll

Thanks for the PR @bono007. We've discussed this request and implementing it has its quirks and compromises. We've investigated several options and none of them (including this one) are satisfactory.

Taking a step back, we'd like to revisit @AutoConfigureTestDabase entirely, I'll comment in that issue shortly. Thanks again.

Comment From: onobc

No worries @snicoll . Every time that I dig into something, even if it does not get merged, I get more familiar w/ the codebase - win/win. Also,I am excited about #19038 and support for TestContainers.