openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <>
Subject Re: Perform automatic drop and create db schema
Date Tue, 02 Jan 2007 22:43:10 GMT

The problem with that is that if there are restrictive foreign keys,  
it can be a little more complicated than just running through each of  
the tables and deleting each one (and unfortunately, SQL strangely  
doesn't allow multiple tables in delete clauses, a la "delete from  
table1, table2").

It's still probably faster than dropping the table and re-creating  
it, though.

On Jan 2, 2007, at 5:33 PM, Shay Banon wrote:

> 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: 
> automatic-drop-and-create-db-schema-tf2909915.html#a8132118
> Sent from the open-jpa-dev mailing list archive at

View raw message