db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Zeckoski" <aar...@vt.edu>
Subject Re: Embedded database which only stores data in memory?
Date Wed, 05 Nov 2008 17:36:18 GMT
Thanks for the responses.

To answer the earliest question above, we are just using Derby for
testing. There are a couple major missing features that make it
unsuitable for our database needs for production. We were using HSQLDB
for testing before but have found the lack or true transactions to be
a real issue (i.e. not catching TX problems in the tests). It is
extremely easy to setup and very very fast to start though so those
aspects of HSQLDB made it almost ideal.

The suggestion about looking at the test cases seems reasonable so I
will do that shortly.
I am guessing you mean the stuff here right?
I had a little trouble figuring out the source structure so let me
know if this is the wrong stuff to be looking at.

There is still a big issue no one in this thread has addressed yet and
that it the fact that derby creates files in the file system for each
test which we have to manually clear (or end up with tests that fail
because the derby database is already there and has unexpected data in
it). We are trying to drop derby in without changing our tests much
and so far I have been able to limit the changes to about 200 lines of
code (which already seems like a lot). Unfortunately, this is playing
havok with our CI server because we have to run an extra script now to
clear out the derby files before and after each build (just to be
I imagine there must be some option to disable the files creation. If
anyone knows how to do this please let me know.
The startup time is annoying but we can live with slower tests if they
are more reliable.

Apologies if these are naive questions or I come off a bit strong. I
am under some time pressure here and vastly underestimated how long it
would take to switch from HSQLDB to Derby for testing.
Suggestions appreciated.

On Wed, Nov 5, 2008 at 12:26 AM, Bryan Pendleton
<bpendleton@amberpoint.com> wrote:
>> Just to chime in here.  We also use Derby for deployment, and are having
>> the same grief with setup time for unit tests
> For what it's worth, Derby itself uses Derby in its own unit tests (of
> course), and overall we have quite good performance, I believe, in the
> Derby unit tests themselves.
> The Derby source tree contains extensive tests and test utilities, and
> is a great source of ideas about how to set up unit tests to work with
> a database efficiently.
> You might try exploring that body of testing code, and you might try
> contacting the folks on the derby-dev list to discuss the particular
> issues you're seeing.
> There's also an extensive section in the Derby wiki which discusses
> the technique behind the Derby unit testing harness.
> I believe that, with a certain amount of care, you should be able to
> achieve quite good performance for your unit testing using Derby.
> thanks,
> bryan

Aaron Zeckoski (aaronz@vt.edu)
Senior Research Engineer - CARET - Cambridge University
Sakai Fellow - [http://aaronz-sakai.blogspot.com/]

View raw message