Clinton, instead of dropping the database for tests, could you use something like dbunit which can help set the state of the db consistently in testing.
See http://dbunit.sourceforge.net for details. On Wed, 9 Feb 2005 17:33:17 -0700, Clinton Begin <[EMAIL PROTECTED]> wrote: > Thanks, but I know why it's slow. :-) Disk I/O vs. memory. > > To ensure test isolation, my unit tests drop and recreate the database > to a consistent state between each test. Sure I could rollback > transactions (which is a questionable test) or manually undo each test > consequence (which is work). This is so much easier. :-) > > As far as I can see, Derby doesn't have an in-memory mode (i.e. no > disk involved). > > I'm sure Derby performs quite well under normal use. > > Cheers, > Clinton > > On Wed, 09 Feb 2005 16:22:43 -0800, Jean T. Anderson > <[EMAIL PROTECTED]> wrote: > > Clinton Begin wrote: > > > > >Hi all, > > > > > >I love Derby, but for unit testing it's just too slow. We used to use > > >HSQLDB before iBATIS joined ASF, but I switched to Derby it because I > > >wasn't sure if HSQLDB was compatible with the ASF license. > > > > > >Thoughts? > > > > > > > > maybe ask [EMAIL PROTECTED] why it's so slow? Perhaps you might be > > encountering common pitfalls. > > > > just a suggestion, > > > > -jean > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- http://www.multitask.com.au/people/dion/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
