The problem with that is that if there are restrictive foreign keys, it can be a little more complicated than just running through each of the tables and deleting each one (and unfortunately, SQL strangely doesn't allow multiple tables in delete clauses, a la "delete from table1, table2").

It's still probably faster than dropping the table and re-creating it, though.


On Jan 2, 2007, at 5:33 PM, Shay Banon wrote:


Automatically clean that data without dropping the tables makes even more
sense. That would be a really cool feature.


Patrick Linskey wrote:

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




--
View this message in context: http://www.nabble.com/Perform- automatic-drop-and-create-db-schema-tf2909915.html#a8132118
Sent from the open-jpa-dev mailing list archive at Nabble.com.


Reply via email to