Our implementation of bitemporal library had a sample client. The integration test cases in the client project run nightly to affirm the veracity of the actions. To see the client in action, it needed an underlying table on a dataserver. To get the ball rolling, we initially housed it in the sandbox DB of a dev dataserver. However, it regularly went missing giving us monday morning pains. Next, we decided to move it to one of the databases that we owned on the dev dataserver. However, the monday morning pain changed to a monthly pain coinciding with the data server refresh cycles when the tables on the database would go missing again. We could have considered moving these tables to the production data server, but it would be undesired clutter to a newcomer. As an alternate route, we just pointed it to a local dataserver instance running on one of our colleagues machines. And yes, you guessed it right – when the machine was down for reboots or other maintenance, again failures though we needed to be especially unlucky for that to happen! Here an embedded database seemed to fit the bill nicely
- database only for the lifetime of the running of the integration test.
- schema that hardly changed
- handful of prepopulated data
- no fancy performance requirements and need for high quality indices
Spring 3 has made this incredibly dumb for everyone to use. <jdbc:embedded-database> is all you need. Provide it with the schema and testdata files and you are good to go! The directive returns a dataSource handle which can be passed around to your txnManager, sqlMapConfig and everyone else who wants a javax.sql.DataSource. The default implementation used is HSQL. Other out-of-the-box implementations available are H2 and DERBY. Whichever provider you choose, just ensure that its driver is available on the classpath (e.g. if HSQL then put org.hsqldb:hsqldb on your test classpath). There were a few nuances (e.g. using HSQL):
- Absence of support for schemas
- Unable to handle square brackets
- Weird datetime format (has to be yyyy-MM-dd hh:mm:ss only – yyyyMMdd hh:mm:ss is not liked by it)
- Unable to recognize GO and USE keywords
- Only single database accessible via a given datasource – so not possible for multi db join use cases
- No user configuration – every operation is with SA privilege. There seems to be support for this in DERBY though
References:
No comments:
Post a Comment