tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Saint Croix" <>
Subject Fwd: Nuking tables on tearDown() for CRUD tests
Date Wed, 09 Jan 2008 01:59:21 GMT
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.


---------- Forwarded message ----------
From: Adam Hardy <>
Date: Jan 8, 2008 5:52 PM
Subject: Re: Nuking tables on tearDown() for CRUD tests

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
> it is probably necessary to manually find a list of all of the entities of
> 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
> to say why, and that's alright.  If we need to build an example
> 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
be ordered to take account of referential integrity constraints.

DbUnit also allows you to store all data in XML files which can be loaded
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
this, but it's paid dividends.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message