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 [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.
