Marina,
I added following changes to the attached fix.
* Do not ignore table creation failure of model table creators. If those
failures are ignored, it is hard to find the cause of test failures.
* Add "clean-db" Ant target which drops all tables of database.
* Some cleanup.
I've run tests several times with this change and had no problem. Please let
me know if there is another problem.
Full change list is in the issue comment.
https://glassfish.dev.java.net/issues/show_bug.cgi?id=1380
Also I added comments about "clean-db" to readme.txt. Feel free to modify
it.
Thanks
-Wonseok
On 10/27/06, Wonseok Kim <guruwons_at_gmail.com> wrote:
>
> Great tool! Does it run on all types of database?
>
> How about adding isql.jar to entity-persistence-tests and making a ant
> target like "clean-db"?
> Then we can document it in readme file.
>
> I think we should notify team to clean database once after checking in
> this change, with new email title.
>
> Thanks
> -Wonseok
>
> On 10/27/06, Marina Vatkina <Marina.Vatkina_at_sun.com> wrote:
> >
> > OK. It does run correctly on a clean database. How would we document
> > this?
> > I'm lucky to know a utility developed at some point for cmp testing that
> > is now checked in under <ws>/glassfish/appserv-tests/lib/isql.jar and
> > which
> > can drop all tables on the cmp supported databases:
> >
> > java -classpath <driver>:<ws>/glassfish/appserv-tests/lib/isql.jar
> > isql.DropTables <url> <user> <pwd> <driver-class-name>
> >
> > But others might miss this discussion and not knowing the dependencies
> > between the tables, manual drop can be quite time consuming :(.
> >
> > What should we do?
> >
> > thanks,
> > -marina
> >
> > Wonseok Kim wrote:
> > > Marina,
> > > I think, there is some misunderstanding.
> > >
> > > Tests don't need run on clean database always, but need to clean once
> > > with this modifications.
> > > This is because previously generated foreign key constraints by ddl
> > > generation can block drop some tables.
> > >
> > > Foreign key constraints generated by ddl generation were different
> > from
> > > the ones by model table creators.
> > > Model table creators drop and create table/constraints always before
> > > tests, so you don't need to clean database, but in your case, I guess,
> > > dropping table by model table creators probably failed due to some
> > > existing foreign key constraints. You can check it by logging level
> > FINEST.
> > >
> > > Thanks
> > > - Wonseok
> > >
> > > On 10/27/06, *Marina Vatkina* <Marina.Vatkina_at_sun.com
> > > <mailto:Marina.Vatkina_at_sun.com >> wrote:
> > >
> > > I ran on the existing database, but did a clean build. If the
> > tests
> > > need a clean database, they must either remove all used tables at
> > > the end, or clean up all the tables at the beginning, right? I
> > don't
> > > think that manual cleanup should be a pre-requisite for the run.
> > >
> > > I'm really not comfortable checking in the changes without an
> > ability
> > > to have a clean run. Tom, do you have an idea?
> > >
> > > thanks,
> > > -marina
> > >
> > > Wonseok Kim wrote:
> > > > Did you run tests on clean database?
> > > > I've run tests several times, but there was no failure.
> > > >
> > > > I don't know what cause the situation, but DDL generation is
> > > disabled,
> > > > so it will not remove existing tables at deploy time (Instead,
> > each
> > > > model table creator will recreate table before running tests).
> > > >
> > > > - Wonseok
> > > >
> >
>