db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <Craig.Russ...@Sun.COM>
Subject Re: RETRY: Transient instance referencing a detached instance?
Date Thu, 06 Oct 2005 22:04:17 GMT

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.



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:andy@jpox.org]
>> 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message