Read DBUnit configuration from Spring properties

It seems that #483 does not cover the case where DBRider is used on a @SpringBootTest and should use the Spring Properties from that test’s Spring context for its configuration. I’m not sure but I don’t think these Spring Context Properties are made into System Properties (they’re not environment properties obviously, since they can be read in a lot of ways by Spring). I think DBRider would have to rely on Spring’s EL (or some other Spring API) to resolve those properties against the running test Sping Context.

E.g.: SomeTest.java

@SpringBootTest
@DBRider
@DataSet("datasets/some-dataset.xml")
public class SomeTest {
    ...
}

dbunit.yml

caseInsensitiveStrategy: !!com.github.database.rider.core.api.configuration.Orthography 'LOWERCASE'
columnSensing: true
properties:
  batchedStatements:  true
  schema: ${spring.datasource.username}

With DBRider v1.34.0, I get the error:

...
Caused by: org.dbunit.dataset.NoSuchTableException: The table 'sometable' does not exist in schema '${spring.datasource.username}'
	at app//org.dbunit.database.search.AbstractMetaDataBasedSearchCallback.getNodes(AbstractMetaDataBasedSearchCallback.java:186)

[rmpestano]

I see, we could do that inrider-springas we don’t want to depend on spring in rider-core. It would be nice to do such integration in rider-junit5 module as we also have some integration there.

[netmikey]

Ok I see our misunderstanding now. Let me try to explain.

Spring can load its configuration properties in a lot of different ways. Them being system properties is only one of a lot of options. They can be specified via properties files, yaml files, command-line arguments, configuration servers, custom implementations, etc. etc. There’s even a very elaborate way and order for overriding them. In our specific case, we generate test-configuration files that we load into our @SpringBootTests, but in order to play nice, DBRider should rely on Spring to resolve these properties. That’s why I proposed to rely on Spring’s EL when a Spring Context is available. As a fallback, when Spring is not available, DBRider could use its own implementation to read System and Environment properties (as it does now).

So in order to integrate well into the Spring ecosystem, what we’d need is:

graph TD;
    P["properties file"]-->Spring;
    Y["yaml file"]-->Spring;
    C["command-line argument"]-->Spring;
    ETC["..."]-->Spring;
    E["environment variable"]-->Spring;
    S["system property"]-->Spring;
    Spring-->DBRider;

What we have now is:

graph TD;
    P["properties file"]-->Spring;
    Y["yaml file"]-->Spring;
    C["command-line argument"]-->Spring;
    ETC["..."]-->Spring;
    E["environment variable"]-->Spring;
    S["system property"]-->Spring;
    E-->DBRider;
    S-->DBRider;