Inconsistent dbunit behaviour between platforms with null dates using in-memory h2

Question

I'm running into an interesting issue here with a DBUnit test.

We have some code that we test with DBUnit tests and a xml dataset. I have inconsistent test results with exactly the same dataset and code files among platforms, so I decided to follow the trail as I will be refactoring a part of the DB Access classes.

The issue I'm running into is the following:

1. The Dataset has 3 records that match a certain query defined in a hbm file.
2. The query does an "order by DATE_FIELD desc", however not all the records in the dataset have this DATE_FIELD set (meaning it should be interpreted as null or the default value from the scripts, which are also identical on both platforms).

On one platform (Linux-server) where Maven runs the tests, they are all OK, however on my PC with Windows, the records are extracted from the database (dataset) with a different order, so I get an error when the test validates the order of the records.

So, I know that modifying the dataset will get my tests to go green on both sides, but if someone wrote this dataset without a date column in one of the records, he might have known about some business rule I'm not aware of, so I'm really not modifying the scenario as it might cause unforseen future problems.

After searching for an answer, I'm modifying the question. The answer I'm looking for, how do I get the H2 database to be consistent with null dates on different platforms. What parameter do I have to set to get NULLS FIRST or NULLS LAST for the whole DB without touching queries?

Thank you very much and regards.

Answer 1

Well,

I'm answering my own question as I found an answer, a better follow-up would be nice but I think this gets to the point.

I followed the instructions on this page:

http://www.h2database.com/javadoc/org/h2/constant/SysProperties.html

And set the sortNullsHigh property on runtime, before loading the driver:

System.setProperty("h2.sortNullsHigh", "true");

Maybe later we will see a way to get it into a config file, after all the central unit tests run with jenkins/maven and there the property is set properly.

Regards