On Jul 20, 2007, at 3:27 PM, Dave wrote:
On 7/20/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:1. having JPA complain about using an object after it is removed seems abit ridiculous. There are very valid reasons to do this, such as theexample below. If you really can't work around this then we should plan to change the various removeXXX() methods to return a safe copy of thedeleted object that can continue to be used.JPA did not complain, but it did set fields of the object to null and the result was an NPE in the invalidate method. I think its debatable whether an object should continue to be valid after it is removed/deleted/whatever.
The JPA spec says that the non-generated fields/properties of removed instances are as they were when the remove method was called.
But I'm still a bit confused by the requirement to access fields of a deleted instance. You have said that the instance doesn't exist any more, so what are you expecting of the instance?
If you really do need to know what the fields were when the entity used to exist, I'd agree that you need to copy the fields you are interested in before you delete the entity. Maybe use the clone() method?
2. moving the invalidation call before the removal is technically incorrect because then if there is an error during the removal you'vemistakenly invalidated the template. while this isn't a huge problem inthis particular situation it's still not a proper solution and i amguessing that there is somewhere else in the code where doing the samething could cause more problems.Yes. I think it's pretty safe to say that the JPA code needs more testing.
All code needs more testing...;-) Craig
- Dave
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
