openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <adam....@cyberspaceroad.org>
Subject Re: Nuking tables on tearDown() for CRUD tests
Date Tue, 08 Jan 2008 23:52:19 GMT
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