Hi Pinaki, On Mar 11, 2009, at 10:46 AM, Pinaki Poddar wrote:
Hi Craig, We are in difficult position if JPA Spec *does not* change the methodsignature to return the detached instance (be it a copy or the original). I had mailed to Kevin (and now you:) to place such a request with JPA Speccommittee so that OpenJPA can remain backward compatible.
I can see an advantage in *not* being backward compatible. If backward compatible, the application silently fails if the user doesn't read the release notes and doesn't change the configuration.
So it might actually be an advantage to throw an exception (signature mismatch) if the user just tries to run with the new incompatible signature OpenJPA implementation.
Craig
We have not yet changed the API signature of detach() for OpenJPA as JPA 2.0 detach() is not yet on the published draft version but soon will be (within this week, I suppose). Because detach() still returns an instance, Ihad overlooked the question you raised. A test case for new behavior is in org.apache.openjpa.persistence.detachment.TestDetach.Old behavior with the new configuration is indirectly tested by the whole test corpus. But few tests in the corpus that failed with the new behaviorand I had to change their configuration to emulate old behavior are org.apache.openjpa.persistence.detachment.TestNoCascadeOneToOneMerge org.apache.openjpa.persistence.simple.TestFlushBeforeDetach.java No code change but only configuration change to"openjpa.Compatibility", "FlushBeforeDetach=true,CopyOnDetach=true"Regards -- Pinaki Craig L Russell wrote:Hi Pinaki, Since the JPA signature has no return value, how can the user get the detached objects?Do you have a test case for the old behavior with the new configuration?Regards, Craig On Mar 10, 2009, at 3:05 PM, Pinaki Poddar wrote:Hi Craig, I understand your concerns because I had similar ones. That is why thischange does retain the past behavior exactly as it was. The user only requires the following configuration to get exactly the same behavioropenjpa.Compatibility=FlushBeforeDetach=true,CopyOnDetach=true In fact, JDO having a separate signature as detachCopy() is a good news because then we can add the same signature to Broker so that the user will not even need the above configuration for backward compatible behavior. Regards -- -- View this message in context: http://n2.nabble.com/Re%3A-svn-commit%3A-r751910---in--openjpa-trunk%3A-openjpa-kernel-src-main-java-org-apache-openjpa-conf--openjpa-kernel-src-main-java-org-apache-openjpa-kernel--openjpa-kernel-src-main-java-org-apache-tp2458104p2458226.html Sent from the OpenJPA Developers mailing list archive at Nabble.com.Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!-- View this message in context: http://n2.nabble.com/Re%3A-svn-commit%3A-r751910---in--openjpa-trunk%3A-openjpa-kernel-src-main-java-org-apache-openjpa-conf--openjpa-kernel-src-main-java-org-apache-openjpa-kernel--openjpa-kernel-src-main-java-org-apache-tp2458104p2462775.html Sent from the OpenJPA Developers mailing list archive at Nabble.com.
Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[email protected] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
