Hi Tom
Comments inline.
Tom Ware wrote:
> This sounds like a good potential feature. I think the feature and
> proposal should be documented in the issue tracker.
>
> Some questions and comments that immediately come to mind:
> - Are there any users we know of that are currently experiencing this
> issue when running on SE?
I have not heard from any users about this issue.
> - My vote would be against having this as the default behavior in SE.
> To truely work, it relys on the presence of a file that may or may not
> be present (especially if an SE application is moved around). This
> becomes an especially big concern when using the default file names
> since multiple applications may deploy that result in the file
> appearing in the same place, potentially resulting in very confusing
> results - especially for users that do not even know this feature
> relys on the presence of a file.
> - How are we picking the features we work on for the next release?
> Are we building a list of features? Are we prioritizing them?
I will punt the above 2 queries to Marina, who should be in a better
position to answer them.
Thanks
Pramod
>
> -Tom
>
> Pramod Gopinath wrote:
>
>> 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
>>>>>
>>>>
>>
>>
>>
>