Hi Pramod,
Sorry for not writing back sooner. It's been quite a busy week since
about half of our team is currently on vacation.
A few questions:
1. I thought we solved this problem by allowing TopLink to write the SQL
files and having GlassFish make use of them.
2. Is the additional functionality you are asking for to have TopLink
now manipulate the SQL files instead of Glassfish? If not, could you
provide some further details?
3. What is the motivation for this change?
And a comment:
- We should definitly enter a feature in the issue tracker for any of
these kinds of issues. It sounds like we will have to figure out the
process that decides which features we want to implement first fairly soon.
-Tom
Pramod Gopinath wrote:
> Hi Tom
> Not sure if you had seen this message. Any comments ?
>
> Thanks
> Pramod
>
>
> Pramod Gopinath wrote:
>
>> 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
>
>
--
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com