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 Thu, 06 Nov 2008 08:51:40 GMT
Do you have the code for this that you can share?

On Wed, Nov 5, 2008 at 7:31 PM, Jim Newsham <jnewsham@referentia.com> wrote:
>
>
> No need for manual deletion or an external script... just clear out the
> database in your test tear-down code.  Here is our strategy (junit 4.x):
>
> - Before all test cases (@BeforeClass):  Generate a temporary directory
> randomly; create a database there, to be used by tests.
> - After each test case (@After):  Drop all tables from the database
> - After all test cases (@AfterClass):  Delete the temporary directory
> recursively.
>
> Jim
>
>> -----Original Message-----
>> From: azeckoski@gmail.com [mailto:azeckoski@gmail.com] On Behalf Of Aaron
>> Zeckoski
>> Sent: Wednesday, November 05, 2008 7:36 AM
>> To: Derby Discussion
>> Subject: Re: Embedded database which only stores data in memory?
>>
>> 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?
>> http://svn.apache.org/repos/asf/db/derby/code/trunk/java/testing/org/apach
>> e/derbyTesting/
>> 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
>> sure).
>> 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.
>> -AZ
>>
>>
>> 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
>> [http://bugs.sakaiproject.org/confluence/display/~aaronz/]
>> Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
>
>
>
>



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

Mime
View raw message