Reploy inline:
Marina Vatkina wrote:
>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).
>
>
When the feature is enabled, I agree, that is the way it should work.
By default, this feature should not be enabled, it should, instead be
enabled by a property.
As I mentioned above, enabling this feature by default can cause
issues. Here is a summary:
1. When enabled by default, every application will use the same
filenames (the default filenames), so enabling this feature by default
could become quite confusing to users who end up running different
applications out of the same directory.
2. The create and drop functionality will be different if an application
is moved
3. Users will not know we are using the file system and that could cause
confusion
Perhaps, we can enable this feature IFF the users provides a filename.
Alternately, we could provide a property that specifically enables this
property - and then the defaults could be used.
>
>
>
>>>- 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>
>
>