IMO, a more valuable option would be a way to delete all records in all
mapped tables, rather than doing unnecessary schema interrogation.
Additionally, note that with JPA, deleting all records during setUp() is
as easy as 'em.createQuery("delete from Employee").executeUpdate();'
-Patrick
--
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
> -----Original Message-----
> From: robert burrell donkin [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 02, 2007 1:39 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Perform automatic drop and create db schema
>
> On 1/2/07, Craig L Russell <[EMAIL PROTECTED]> wrote:
> > For What It's Worth:
> >
> > +1 on the drop-tables feature for OpenJPA. But I would caution
> > against using it on each test.
> >
> > Sadly, my experience is that drop-create-tables is 99.9% of the time
> > taken in a typical test.
> >
> > The JDO TCK runs hundreds of tests and we drop-create tables only on
> > demand. The drop-create step takes several minutes compared to a few
> > seconds to actually run the tests.
>
> yeh - dropping then recreating isn't very efficient but is effective
>
> i've found that it's hard to educate developers unfamiliar with
> automated testing. creating good integration tests is important but
> takes a long while. too often neglected due to time pressure. i
> suspect that tool developers could do more to help.
>
> for example, IMHO containers should ship with integrated code coverage
> tools. there are good enough open source ones but since they are not
> bundled with containers they are not used as widely as they should be
> in commercial development work.
>
> > After several years of doing this kind of work, I've concluded that
> > the best practical strategy (we tried beating up the
> database vendors
> > to make drop-create as fast as insert/delete rows, to no
> avail) is to
> > write your tests such that at the beginning of the test, you create
> > your test data and at the end of the test, you delete the test data,
> > leaving the database in an empty state.
>
> +1
>
> but this is where a side door would be of most use. sophisticated
> object relational layers generally make it relatively slow and
> unnatural to just delete everything in a table. which is as it should
> be. it'd just be cool to able if the tool developers also created
> testing only side doors.
>
> i have an idea that this is all reasonably easily doable but isn't
> well known or packaged up into tools which are easy to learn.
>
> it would be very cool to be able to start a recording tool in setup to
> intercept and record every create, update, delete in the data access
> layer then in tearDown just ask the data access layer to undo
> everything that was done.
>
> it would also be very cool to have a complete dump and replace
> facility for black-box-in-container functional testing. in setup, just
> push a load of data as xml. the data access layer deletes data from
> all the tables specified and inserts the given data.
>
> easy, dynamic flushing of all object caches would also be useful.
>
> (sadly, i'm really interested in meta-data ATM, both email and source
> auditing so there's not much chance of hacking together something
> which demonstrates what i mean any time soon...)
>
> - robert
>
