Re: Have toplink code drop the tables from the database based on the old drop file
Yes.
thanks,
-marina
Rebecca Parks wrote:
> Is this relevant to Issue 919?
>
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=919
>
> June
>
> Pramod Gopinath wrote On 08/17/06 11:18,:
>
>> Hi Tom
>> A long time ago we had discussed this as part of introducing
>> java2db support into the toplink code. At that point of time I had
>> concentrated on introducing code into the glassfish framework to
>> support this. Based on the current code base, I think we need to
>> explore this option again. Below is a very rough proposal that I
>> wanted to run by you. It would be great to hear your comments on this
>> topic.
>>
>> _/Problem Description:/_
>> As you are aware toplink drops the tables from the database based
>> on the new entities that are part of the current application (pu in
>> the case of EJB3.0). This is wrong because the entities could have
>> changed and we should always try to drop the old objects (tables/FKs...)
>>
>> _/Proposed solution:/_
>> The code in
>> glassfish/entity-persistence/src/java/oracle/toplink/essentials/ejb/cmp3/EntityManagerFactoryProvider.java.generateDdlFiles()
>>
>> is aware of the drop files location and where we need to drop the
>> entities. Based on the options then it calls
>> createOrReplaceDefaultTables(). In there we could try to read the drop
>> file and try to drop the entities. If this fails because the dropFile
>> does not exist, then the code could continue to do what it does now
>> (mgr.replaceDefaultTables(true)).
>>
>> _/Issues to be addressed:/_
>> If we go down this path, need to do the following
>> 1. read the drop file
>> 2. get a hold of the connection (that is currently used to create the
>> tables directly in the database if the user has selected the option)
>> and use that option to execute the statements read as part of 1.
>>
>> Thanks
>> Pramod