This was one suggestion by Adam Hardy on the [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> Date: Jan 8, 2008 5:52 PM Subject: Re: Nuking tables on tearDown() for CRUD tests To: [EMAIL PROTECTED] 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.
