-
Notifications
You must be signed in to change notification settings - Fork 41.3k
Closed
Description
Issue
The current default for spring.datasource.generate-unique-name
(false
) causes issues in combination with the default used for Hibernates DDL setting spring.jpa.generate-ddl
(create-drop
) in the context of Spring Test's context caching. I've attached a sample project that shows the issue.
Steps to reproduce
- Unzip the linked file
- Run
mvn clean test
- See the third test case fail as it cannot find data inserted during bootstrap of the context for the first test case.
Context
Here is what's going on:
- We have two different context bootstraps. One that's inserting a bit of commonly shared data the application needs. The other one is not including that component. This is just a dummy setup for test cases that use a diverse set of configurations and include components that manipulate the database.
- When the first test bootstraps, an embedded database instance is created, the schema is created and the component sets up the data in the database.
- When the second test bootstraps, the default of
create-drop
causes the database schema being wiped and recreated. As this context does not contain the component setting up the reference data, the database remains initialized but unpopulated. This is fine for this particular context. However, as the database is shared across the application contexts, the other cached one is affected, too. - The third test case uses the same context as the first one but now doesn't find the data wiped by the second one anymore.
Underlying problems
There are a couple of problematic aspects about the current setup:
- A bean definition in an application creating a resource that's shared across application contexts is unexpected as that's not the way it works for any other bean.
- Whether the behavior imposes a problem is dependent on the order of the test classes during JUnit execution. If the third test is executed before the second one the problem disappears. This makes diagnosing the problem even harder.
Workarounds
- Explicitly setting
spring.datasource.generate-unique-name=true
causes database instances to be created perApplicationContext
.
Proposed solution
- Change the default of
spring.datasource.generate-unique-name
totrue
.
Side-effects of the solution
- In an internal discussion, @wilkinsona mentioned that a flip in the default would probably cause issues in DevTools, as it is re-bootstrapping the
ApplicationContext
and – with the new default – would lose the data entered while using the application. This could be mitigated by letting DevTools explicitly disable the property by default.
Further references
- Allow configuration to specify randomly generated database name #7004
- Make in-memory database tests default to using random name #7102
AFAIK, @sbrannen had a few thoughts on that as well.
Metadata
Metadata
Assignees
Labels
type: enhancementA general enhancementA general enhancement
Type
Projects
Relationships
Development
Select code repository
Activity
sbrannen commentedon May 10, 2019
Yes, I always advocate generating a random database name for embedded databases in Spring integration tests.
Over the years I have seen numerous projects that ran into issues with
@DirtiesContext
as well as the LRU eviction policy for theContextCache
, and the only viable solution was using a random database name.In fact, I updated the Spring Framework reference manual quite awhile ago (several years?) to point that out.
In summary, if it's feasible I think it would be beneficial if
spring.datasource.generate-unique-name=true
was the default in Spring Boot for integration tests.philwebb commentedon May 10, 2019
Digging though the code a bit we think this might be a safe change to make but we'll need some time to experiment to make sure there are no unexpected side effects.
wilkinsona commentedon May 10, 2019
See #4699 for the DevTools side of things.
odrotbohm commentedon Oct 28, 2019
Can we bring this on the table for 2.3 again?
philwebb commentedon Nov 6, 2019
@odrotbohm Yeah, we'll try again to get this into the next version
nightswimmings commentedon Jan 29, 2022
@wilkinsona @philwebb But given the context caching and reuse, isn't this gonna open several db instances in memory?
wilkinsona commentedon Jan 29, 2022
Yes, and that is intentional and desirable as explained above by @odrotbohm and @sbrannen.
OrangeDog commentedon Jun 7, 2022
This has the side-effect that
name
now does nothing unlessgenerate-unique-name
is also overridden tofalse
.I would expect setting the
name
to set the name, with no other properties set.wilkinsona commentedon Jun 7, 2022
I'm not sure why you have that expectation. The
name
property's documentation states that it is the "Datasource name to use ifgenerate-unique-name
is false".