tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Nuking tables on tearDown() for CRUD tests
Date Wed, 09 Jan 2008 02:21:58 GMT
I swore I thought I mentioned using fork mode, but just in case.   If  
you use fork mode with the in-memory db, there's nothing to clean.   
Have you experimented with that route.

We're still using jaxb to unmarshall the persistence.xml, but I've  
been thinking of cutting that out which might save you 1 second each  
test.  JAXB takes a while to initialize the first time it's used in a  
vm.

-David

On Jan 8, 2008, at 5:59 PM, Alexander Saint Croix wrote:

> This was one suggestion by Adam Hardy on the users@openjpa list.  I  
> might
> look into dbUnit, but wonder whether it is ideally suited for the  
> container
> injection mechanisms we're using.
>
> Cheers,
> --
> Alex
>
>
> ---------- Forwarded message ----------
> From: Adam Hardy <adam.sql@cyberspaceroad.org>
> Date: Jan 8, 2008 5:52 PM
> Subject: Re: Nuking tables on tearDown() for CRUD tests
> To: users@openjpa.apache.org
>
>
> Alexander Saint Croix on 08/01/08 23:08, wrote:
>> After working with devs on both the OpenEJB and the OpenJPA teams,  
>> I think
>> that for anything other than trivial persistence units and entity
> relations,
>> it is probably necessary to manually find a list of all of the  
>> entities of
> a
>> given type, iterate over that list, and use the  
>> entitymanager.remove()
>> method to clean out the entities in the datastore between unit tests.
>> Although this method is extremely slow and will be a big hit to
>> productivity, I cannot get a succession of "DELETE FROM table"  
>> queries to
>> reliably remove objects without crashing because of entity  
>> relations and
>> foreign keys, and have not yet had the former method crash on me.
>>
>> The "DELETE FROM table" mechanism seems to wreak havoc on the  
>> cascading
>> rules and cause problems for itself when done in succession to  
>> multiple
>> tables--I don't know enough about the guts of the query execution
> mechanism
>> to say why, and that's alright.  If we need to build an example
> application
>> for either project to test this behavior at a later time, I'll be  
>> able to
>> provide a sufficiently complex persistence unit to really stress test
>> things.
>>
>> In the meantime, I really am itching to get back to actual  
>> development, so
>> I'm going to revert and move forward using the other method for the  
>> time
>> being. Thanks to Dain, Panaki, Jacek, Adam, and Patrick.
>
> I recommended DbUnit for handling test data before, and in terms of  
> the
> performance hit, it won't be much problem at all.
>
> However it would require a list of all tables from which to delete,  
> and it
> must
> be ordered to take account of referential integrity constraints.
>
> DbUnit also allows you to store all data in XML files which can be  
> loaded
> fresh
> for each test. Obviously this uses the same list of tables as above,  
> just in
> reverse. And you need to ditch and recreate the entity manager  
> between each
> test. It wasn't quick or easy to set up a system to handle the test  
> data
> like
> this, but it's paid dividends.


Mime
View raw message