Tom,
My comments below...
Pramod Gopinath wrote:
> 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.
Other than Shelly :)
>
>> - 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.
The logic should be - if the file is there, execute it. Otherwise try to
drop as today (i.e. to the best of our knowledge).
>> - How are we picking the features we work on for the next release?
>> Are we building a list of features? Are we prioritizing them?
Right now it's a bug - if you change the app so that FK differ from before,
java2db doesn't work in SE.
But about picking the features we work on for the next release - we need
a proposal :). Do you guys have a wish list? If you do, enter it, we'll
add ours, and ask the world to vote. If the world doesn't vote, they don't
care, and we can have a brainstorming meeting between our 2 teams.
Sounds like a plan?
thanks,
-marina
>
> 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
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>