Hi Tom
No problems with the delay. It takes a long time to see the email on
the alias after I had sent it, so was not sure if it had reached you.
Yes, we did solve this issue on the Glassfish end as we are explicitly
aware of the undeploy/deploy stages. But there is an issue in the java
SE scenario. Since there is no interaction with Glassfish we cannot do
the drop of the correct entities (issue 919). Additionally when we were
initially discussing about java2db and toplink, you guys had mentioned
that you would be interested in hearing a proposal on how this could be
solved such that both javaSE and inside container could be solved.
This proposal would deal with that. Having the code changes done on the
toplink side would take care of both the inside and outside container
cases.
Again the motivation of these changes is to ensure that at drop time we
drop the old entities and the only way to get a hold of them would be
through the script files.
Thanks
Pramod
Tom Ware wrote:
> 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
>>
>>
>