Support for Case INsensitive YML dataset

[rmpestano]

Currently the yml dataset is always case sensitive, see here.

We need to take into account caseSentiveTableNames property and if it is false we should make table names uppercase, as in FlatXMLDataSets.

[rmpestano]

refs #26

[jenskreidler]

Currently facing this issue again at daily work. Mixing databases and technologies (H2 and postgres) with used by database-rider and arquillian-persistence using the same testdata yml files.

Upvoting this issue
Shall I dig into this in order to fix it?

[rmpestano]

Hi, this would be awesome!

Also would be nice to have the same behaviour for json dataset.

Note that the default for caseSensitiveTableNames is false so after this is issue is fixed we will go back to the same behaviour as in dbrider 1.0.0.

[jenskreidler]

Hi @rmpestano,

I've played a bit with caseSensitiveTableNames, propagated the dbUnitConfig to the YAMLDataSet.
I'm ending up in a pitfall calling the AbstractMetaDataBasedSearchCallback.java:183 using org.dbunit.database.IMetadataHandler#tableExists(...). It simply handles the searched table names differently. For H2, it must get uppercase names, for postgres, it must be lowercase (all identifiers - also column names - are folded into lowercase in postgres if not quoted).

To sum up, in order to get rid of this issue, we end up in a vendor specific / forced identifiers syntax (upper or lowercase?) - what we aren't willing to do, are we ?

Option 1: we apply a logic (may be in dbunit.yml) where the default dbrider-configuration is read. It configures the case-sensitive table names folding process in respect to the database driver/vendor/or s.th. else, i.e. if dbrider should convert identifiers to lower or upper case.

Option 2: if we set "caseSensitiveTableNames=false" (=default), we could try both identifier cases: 1) in uppercase, 2) in lowercase (otherwise as it is) and if nothing's found, throw the NoSuchTableException. In this case we have to open a request in the dbunit-community.

Option 3: what about @rmpestano 's idea of introducing the "uppercaseDatasets" config property? (or "uppercaseIdentifiers", because H2 for instance also complains about case sensitive column names...) ?

Option 4: still having s.th. to do with dbunit itself. If we have a look at java.sql.DatabaseMetaData.java, there are methodes like "boolean storesUpperCaseIdentifiers()", "storesLowerCaseIdentifiers()" etc.
Although unverified/tested/a very quick suggestion by me, dbunit could provide some intermediate logic in table/column name retrieval without stepping into an Exception etc. if caseSensitiveTableNames is set to false.

[rmpestano]

Hi @jenskreidler,

first of all thank you very much for your time in contributing to this project!

Now to the questions, I think we should not try to guess the database/vendor specific syntax, I think it is up to the developer to configure caseSensitiveTableNames in his test to match the database where the tests will run.

Taking that as premise, does your change support that?

for example, I will run the tests on H2 then I set caseSensitiveTableNames to false and declare my datasets in lowercase, will dbunit find tables? if yes ok.

On the other hand if I run the tests on postgres then I'll set caseSensitiveTableNames to true and declare my datasets accordingly.

Do you agree? or there is something else I'm missing?

[jenskreidler]

Hi @rmpestano,
in summary: when caseSensitiveTableNames=false, it's up to the database default behaviour. In H2 for instance, identifiers should be in upper case, in postgres for example in lower case. So we do not have a clear-cut behaviour in "case in-sensitve table names - mode".
What about to introduce in dbunit.yml "caseInSensitiveStrategy" (default either upper- or lowercase). This would advice the YamlDataSet how to manage identifiers if and only if caseSensitiveTableNames is false?
Do you agree?

[rmpestano]

Hi @jenskreidler, that's a nice idea!

I think we should default to UPPERCASE in caseInSensitiveStrategy as in-memory db is largely used for testing and also dbrider examples all run in h2/hsqldb.

thank you!