With that change when the user call makePersistent on A having a reference to a detached B(1), A will get replaced the reference to B(1) with B(2), instance not detached. So far fine, but will the changes made on the detached B(1), get reflected on the instance B(2) currently in cache?
I would say yes, the attachment would happen. Quoting "Matthew T. Adams" <[EMAIL PROTECTED]>: > 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 > > > > >
