I was thinking along the following lines. When the user calls pm.makePersistent(t), where t is a transient instance that may contain a reference to a detached instance, the JDO implementation runs the reachability algorithm. Any detached objects found in the graph are replaced by their corresponding attached copies (perhaps via an implicit pm.attachCopy call). Once the attachment process is complete, the graph consists of transient objects referencing newly attached, and thereby persistent, references. At that point, the use case that already exists today takes over, where the there are transient instances referencing persistent-dirty or persistent-clean instances.
There exists the possibility that more than one distinct detached instance is found that has the same object id as another (two detached copies of the same persistent instance), and I'd say that we do not specify which detached instance gets attached, but the user is guaranteed that one and only one instance is attached, and any references to the different detached copies are replaced by a reference to the one and only attached, persistent copy. Conceptually, this requires two passes through the graph, but it might be possible to do this with only one pass; that's up to the individual implementations. I don't really see any new states here; the transient instances are still transient or persistent-new, and the detached objects' replacements (the attached copies) are either in the persistent-dirty or persistent-clean states. It's entirely possible that I'm oversimplifying the solution here, but it seems doable. Thoughts? --matthew -----Original Message----- From: Craig Russell [mailto:[EMAIL PROTECTED] Sent: Thursday, October 06, 2005 3:04 PM To: [email protected]; JDO Expert Group Subject: Re: RETRY: Transient instance referencing a detached instance? 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'; [email protected] 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!
