openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shay Banon <>
Subject RE: Perform automatic drop and create db schema
Date Tue, 02 Jan 2007 22:33:09 GMT

Automatically clean that data without dropping the tables makes even more
sense. That would be a really cool feature.

Patrick Linskey wrote:
> IMO, a more valuable option would be a way to delete all records in all
> mapped tables, rather than doing unnecessary schema interrogation.
> Additionally, note that with JPA, deleting all records during setUp() is
> as easy as 'em.createQuery("delete from Employee").executeUpdate();'
> -Patrick
> -- 
> Patrick Linskey
> BEA Systems, Inc. 
> _______________________________________________________________________
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it. 
>> -----Original Message-----
>> From: robert burrell donkin [] 
>> Sent: Tuesday, January 02, 2007 1:39 PM
>> To:
>> Subject: Re: Perform automatic drop and create db schema
>> On 1/2/07, Craig L Russell <> wrote:
>> > 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.
>> yeh - dropping then recreating isn't very efficient but is effective
>> i've found that it's hard to educate developers unfamiliar with
>> automated testing. creating good integration tests is important but
>> takes a long while. too often neglected due to time pressure. i
>> suspect that tool developers could do more to help.
>> for example, IMHO containers should ship with integrated code coverage
>> tools. there are good enough open source ones but since they are not
>> bundled with containers they are not used as widely as they should be
>> in commercial development work.
>> > 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.
>> +1
>> but this is where a side door would be of most use. sophisticated
>> object relational layers generally make it relatively slow and
>> unnatural to just delete everything in a table. which is as it should
>> be. it'd just be cool to able if the tool developers also created
>> testing only side doors.
>> i have an idea that this is all reasonably easily doable but isn't
>> well known or packaged up into tools which are easy to learn.
>> it would be very cool to be able to start a recording tool in setup to
>> intercept and record every create, update, delete in the data access
>> layer then in tearDown just ask the data access layer to undo
>> everything that was done.
>> it would also be very cool to have a complete dump and replace
>> facility for black-box-in-container functional testing. in setup, just
>> push a load of data as xml. the data access layer deletes data from
>> all the tables specified and inserts the given data.
>> easy, dynamic flushing of all object caches would also be useful.
>> (sadly, i'm really interested in meta-data ATM, both email and source
>> auditing so there's not much chance of hacking together something
>> which demonstrates what i mean any time soon...)
>> - robert

View this message in context:
Sent from the open-jpa-dev mailing list archive at

View raw message