Re: RETRY: Transient instance referencing a detached instance?

[Craig Russell]

Hi, If you would, please go through the state transitions of detached objects becoming persistent via makePersistent or via reachability. Include what happens to detached objects at commit and rollback. I was unable to do this without creating numerous additional states (detached-persistent, detached-persistent-dirty, detached-persistent-deleted) and it was hideous.  Let me know what you find by doing the analysis and we can talk about it. The clean way of doing it is still to allow mixing transient instances with either detached or persistent object graphs but keeping detached and persistent graphs distinct. Thanks, Craig On Oct 5, 2005, at 5:31 PM, Matthew T. Adams wrote: Excellent.  Unless there's some technical reason that a user advocate like me can't see, let's make this change.  Craig, others, can you please comment? --matthew -----Original Message----- From: Andy Jefferson [mailto:[EMAIL PROTECTED]]  Sent: Wednesday, October 05, 2005 12:09 PM To: 'JDO Expert Group'; jdo-dev@db.apache.org Subject: Re: RETRY: Transient instance referencing a detached instance? Would it be cleaner to not allow transient instances to be  included in attachCopy() graphs at all?  Sounds that way to me. No, I'd like to continue to allow transient instances to be  included in attachCopy graphs.  I'd like to **add** the ability for  detached objects to be included in makePersistent graphs. I'll second this requirement. I asked for it on 16 Sep - see the posting in the EG archives titled  "makePersistent with a detached object reachable". We need a consistent interface for persistence, and having one method  (makePersistent) doing things one way and another(attachCopy) doing it  another doesn't help IMHO. A user wants to persist a new object. They want to relate it  to another object  (in this case detached, but it could be any old object), and  then do the  persist. Having to work out which method to call in what  circumstances,  dependent on what objects you just happen to have in the graph is not  user-friendly. --  Andy 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