Wonsoek, Marina,
Thanks for fixing this issue and checking in the fix.
-Tom
Wonseok Kim wrote:
> 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
> <mailto: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
> <mailto: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>
>> <mailto: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
>> >
>
>