Team,
Please vote your opinion (and say if you are answering
from an experience or just your opinion on the subject).
Q: Which scenario happens more often during development
of JPA applications in a Java SE environment (we don't
expect developers to use java2db on a production run,
right?)?
Scenario 1: The developer runs more than one persistence
app from the same directory.
Scenario 2: The developer modifies classes in a PU and
java2db fails to drop the tables because of changed
constraints (issue 919).
thanks,
-marina
Tom Ware wrote On 08/21/06 08:38,:
> Reply 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>>