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]
