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?
- 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?
-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
>>>>
>>>>
>>>
>>>
>
>
>
--
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com