Mining for gold and finding the fountain of youth: code refactoring unnearths roots that should be yanked

I’m still evaluating StelsXml as a quasi mock for our database. Instead of having our unit tests rely on a database server, we’re trying to represent our database as a large XML file (would be checked in with the unit tests), reducing the overhead in setting up a test environment. The problem is that such a solution would require modifying custom jdbc code and various select statements to adapt to the xml data source…Well, thats not the case with the StelsXml jdbc driver. Simply modify the jdbc connection url and walaaa! I’ve had to dig through the code and xml configuration files to modify the Class loading statement for the jdbc Driver as well as modifying the connection url.
In the process of doing so, we found some database vendor specific code – a bug! Postgres has a ILIKE keyword to make string comparing easier and we’re using it.

The key word ILIKE can be used instead of LIKE to make the match case-insensitive according to the active locale. This is not in the SQL standard but is a PostgreSQL extension. url

Its not what I was looking for, but atleast the research in trying to get the StelsXml driver to work with our system unearthed a code issue that we don’t want in our code.