openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Perform automatic drop and create db schema
Date Tue, 02 Jan 2007 21:07:57 GMT
For What It's Worth:

+1 on the drop-tables feature for OpenJPA. But I would caution  
against using it on each test.

Sadly, my experience is that drop-create-tables is 99.9% of the time  
taken in a typical test.

The JDO TCK runs hundreds of tests and we drop-create tables only on  
demand. The drop-create step takes several minutes compared to a few  
seconds to actually run the tests.

After several years of doing this kind of work, I've concluded that  
the best practical strategy (we tried beating up the database vendors  
to make drop-create as fast as insert/delete rows, to no avail) is to  
write your tests such that at the beginning of the test, you create  
your test data and at the end of the test, you delete the test data,  
leaving the database in an empty state.

JUnit facilitates this by providing a setUp and tearDown. We create  
the test data in setUp and delete it in tearDown. Of course, the  
tearDown might fail, leaving the data in an unpredictable state, but  
it does work 99.9% of the time. That's why we have a common tearDown  
that is very carefully implemented to catch exceptions, retry, etc.


On Jan 2, 2007, at 12:52 PM, Marc Prud'hommeaux wrote:

> Robert-
> I completely agree. We usually just build all the tables once and  
> then just try to make sure all the objects are deleted at the end  
> of the test, but you are correct that this is sometimes more  
> cumbersome than it could be. An easy drop-then-create option would  
> simplify this, although some databases can be notoriously slow with  
> schema interrogation and manipulation that doing it for each test  
> might wind up being prohibitively slow.
> On Jan 2, 2007, at 3:44 PM, robert burrell donkin wrote:
>> On 1/2/07, Marc Prud'hommeaux <> wrote:
>>> Shay-
>>> Unfortunately, we don't have any automatic drop-table feature, but I
>>> agree it would be handy (you might want to make a JIRA report with
>>> the suggestion).
>>> The only other recourse, I think, would be to just manually delete
>>> the database files before running your tests.
>> support for easy integration testing is one area where i think many
>> JDO implementations could really improve
>> it's vital to start with a known database state and clean up after
>> each integration test. this isn't as easy as it should be when you
>> have a complex object-relational mapper with extensive caching. a set
>> of side doors for integration testing would really help productivity.
>> - robert

Craig Russell
Architect, Sun Java Enterprise System
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message