You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig L Russell <Cr...@Sun.COM> on 2005/10/16 21:26:17 UTC
Re: RETRY: Transient instance referencing a detached instance? (was:
Question about attachCopy, transient & detached instances)
Javadogs,
I've reviewed this material and agree with the general conclusion,
that we can add the ability to include detached objects in the
closure of instances for both makePersistent and attachCopy.
The spec as of today requires treating these three types of objects
in the closure differently:
persistent instances
attachCopy throws an exception; makePersistent ignores them
transient instances
attachCopy copies them and creates persistent-new instances;
makePersistent makes them persistent-new
detached instances
attachCopy copies them; makePersistent throws an exception
Here's the change as I would propose it:
persistent instances
attachCopy ignores them; makePersistent ignores them
transient instances
attachCopy copies them and creates persistent-new instances;
makePersistent makes them persistent-new
detached instances
attachCopy copies them; makePersistent copies them
If we make this change, the behavior of makePersistent and attachCopy
are more similar than today. The differences are in the treatment of
transient instances and whether or not the root objects are returned.
If we like, we can have makePersistent also return the root objects
by making a source-compatible change to the signatures of
makePersistent.
Craig
On Oct 5, 2005, at 11:59 AM, Matthew T. Adams wrote:
> "Wes Biggs" <we...@tralfamadore.com> wrote in message
> news:<ma...@jdo-experts.org>...
>
>> 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.
>
> This use case fell out very naturally for me while working on a
> website that
> uses detached objects. I ended up with a transient User object
> referencing
> a detached Country object, and, of course, when I called
> pm.makePersistent(user), I got an JDOUserException as I should
> have, per the
> spec as it stands right now.
>
> --matthew
>
>
>
Re: Remove pm.attachCopy? (was: RE: RETRY: Transient instance referencing a detached instance? (was: Question about attachCopy, transient & detached instances))
Posted by Abe White <aw...@solarmetric.com>.
> I'd like to get feedback from jdo vendors who have implemented
> detach and attach. I'm really keen on getting user feedback or use-
> cases for attach.
>
> In particular, how do implementations handle transient instances?
> Are there use-cases that demand that transient instances are
> copied? This would be the case if the same transient instance was
> intended to be attached to multiple persistence managers.
We haven't really seen any users who need to attach the same graph
with transient instances to multiple PMs. So consolidating
everything into makePersistent would work for the real-world uses
we've seen.
Re: Remove pm.attachCopy? (was: RE: RETRY: Transient instance
referencing a detached instance? (was: Question about attachCopy,
transient & detached instances))
Posted by Craig L Russell <Cr...@Sun.COM>.
Javadogs,
I'd like to get feedback from jdo vendors who have implemented detach
and attach. I'm really keen on getting user feedback or use-cases for
attach.
In particular, how do implementations handle transient instances? Are
there use-cases that demand that transient instances are copied? This
would be the case if the same transient instance was intended to be
attached to multiple persistence managers.
Please let's hear from you.
Thanks,
Craig
P.S. If we agree to remove attachCopy, there are still some questions.
1. What do we do about the "makeTransactional" boolean flag on
attachCopy? Do we automatically make the attached instances
transactional? That is, default the flag to true, or do we add
another variant on makePersistent?
2. What do we do about the attach callbacks? We could preserve them
and just change the documentation to say that the callbacks are
called during makePersistent for detached objects.
On Oct 18, 2005, at 11:21 AM, Wes Biggs wrote:
> I think this is an excellent idea.
>
> I'd be happy to remove the copy semantic on transient instances in
> order to eliminate the need for a separate method. My feeling is
> that transient instances are likely to be retained as references,
> and it's actually less confusing if those references become
> persistent-new.
>
> Wes
>
> Matthew T. Adams wrote:
>
>
>> I like the convergence in the api, and I also like the suggestion
>> to return
>> the root object(s) from makePersistent, as it increases symmetry.
>>
>> Could attachCopy and makePersistent become one, just
>> makePersistent? The
>> only difference in the proposal as you suggest, Craig, is the
>> handling of
>> transient instances. attachCopy copies instances and makes the
>> copies
>> persistent-new, whereas makePersistent just makes them persistent-
>> new; all
>> other behavior is the same. If we got rid of attachCopy, in favor of
>> makePersistent, and changed makePersistent such that it returns
>> the root
>> object(s) given, then the behavior is covered, except for
>> attachCopy's copy
>> semantic for transient instances. The only difference in the API
>> if we keep
>> attachCopy is the copy semantic for transient instances, which I
>> don't think
>> is all that important.
>>
>> Thoughts?
>>
>> --matthew
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM] Sent:
>>> Sunday, October 16, 2005 12:26 PM
>>> To: JDO Expert Group; jdo-dev@db.apache.org
>>> Subject: Re: RETRY: Transient instance referencing a detached
>>> instance? (was: Question about attachCopy, transient & detached
>>> instances)
>>>
>>>
>>> Javadogs,
>>>
>>> I've reviewed this material and agree with the general
>>> conclusion, that we can add the ability to include detached
>>> objects in the closure of instances for both makePersistent and
>>> attachCopy.
>>>
>>> The spec as of today requires treating these three types of
>>> objects in the closure differently:
>>>
>>> persistent instances
>>>
>>> attachCopy throws an exception; makePersistent ignores them
>>>
>>> transient instances
>>>
>>> attachCopy copies them and creates persistent-new instances;
>>> makePersistent makes them persistent-new
>>>
>>> detached instances
>>>
>>> attachCopy copies them; makePersistent throws an exception
>>>
>>> Here's the change as I would propose it:
>>>
>>> persistent instances
>>>
>>> attachCopy ignores them; makePersistent ignores them
>>>
>>> transient instances
>>>
>>> attachCopy copies them and creates persistent-new instances;
>>> makePersistent makes them persistent-new
>>>
>>> detached instances
>>>
>>> attachCopy copies them; makePersistent copies them
>>>
>>> If we make this change, the behavior of makePersistent and
>>> attachCopy are more similar than today. The differences are in
>>> the treatment of transient instances and whether or not the root
>>> objects are returned. If we like, we can have makePersistent
>>> also return the root objects by making a source-compatible
>>> change to the signatures of makePersistent.
>>>
>>> Craig
>>>
>>> On Oct 5, 2005, at 11:59 AM, Matthew T. Adams wrote:
>>>
>>>
>>>
>>>> "Wes Biggs" <we...@tralfamadore.com> wrote in message
>>>> news:<ma...@jdo-experts.org>...
>>>>
>>>>
>>>>
>>>>> 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.
>>>>
>>>> This use case fell out very naturally for me while working on a
>>>> website that
>>>> uses detached objects. I ended up with a transient User object
>>>> referencing
>>>> a detached Country object, and, of course, when I called
>>>> pm.makePersistent(user), I got an JDOUserException as I should
>>>> have, per the
>>>> spec as it stands right now.
>>>>
>>>> --matthew
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
Re: Remove pm.attachCopy? (was: RE: RETRY: Transient instance referencing
a detached instance? (was: Question about attachCopy, transient & detached
instances))
Posted by Wes Biggs <we...@tralfamadore.com>.
I think this is an excellent idea.
I'd be happy to remove the copy semantic on transient instances in order
to eliminate the need for a separate method. My feeling is that
transient instances are likely to be retained as references, and it's
actually less confusing if those references become persistent-new.
Wes
Matthew T. Adams wrote:
>I like the convergence in the api, and I also like the suggestion to return
>the root object(s) from makePersistent, as it increases symmetry.
>
>Could attachCopy and makePersistent become one, just makePersistent? The
>only difference in the proposal as you suggest, Craig, is the handling of
>transient instances. attachCopy copies instances and makes the copies
>persistent-new, whereas makePersistent just makes them persistent-new; all
>other behavior is the same. If we got rid of attachCopy, in favor of
>makePersistent, and changed makePersistent such that it returns the root
>object(s) given, then the behavior is covered, except for attachCopy's copy
>semantic for transient instances. The only difference in the API if we keep
>attachCopy is the copy semantic for transient instances, which I don't think
>is all that important.
>
>Thoughts?
>
>--matthew
>
>
>
>
>>-----Original Message-----
>>From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
>>Sent: Sunday, October 16, 2005 12:26 PM
>>To: JDO Expert Group; jdo-dev@db.apache.org
>>Subject: Re: RETRY: Transient instance referencing a detached
>>instance? (was: Question about attachCopy, transient &
>>detached instances)
>>
>>
>>Javadogs,
>>
>>I've reviewed this material and agree with the general conclusion,
>>that we can add the ability to include detached objects in the
>>closure of instances for both makePersistent and attachCopy.
>>
>>The spec as of today requires treating these three types of objects
>>in the closure differently:
>>
>>persistent instances
>>
>>attachCopy throws an exception; makePersistent ignores them
>>
>>transient instances
>>
>>attachCopy copies them and creates persistent-new instances;
>>makePersistent makes them persistent-new
>>
>>detached instances
>>
>>attachCopy copies them; makePersistent throws an exception
>>
>>Here's the change as I would propose it:
>>
>>persistent instances
>>
>>attachCopy ignores them; makePersistent ignores them
>>
>>transient instances
>>
>>attachCopy copies them and creates persistent-new instances;
>>makePersistent makes them persistent-new
>>
>>detached instances
>>
>>attachCopy copies them; makePersistent copies them
>>
>>If we make this change, the behavior of makePersistent and attachCopy
>>are more similar than today. The differences are in the treatment of
>>transient instances and whether or not the root objects are returned.
>>If we like, we can have makePersistent also return the root objects
>>by making a source-compatible change to the signatures of
>>makePersistent.
>>
>>Craig
>>
>>On Oct 5, 2005, at 11:59 AM, Matthew T. Adams wrote:
>>
>>
>>
>>>"Wes Biggs" <we...@tralfamadore.com> wrote in message
>>>news:<ma...@jdo-experts.org>...
>>>
>>>
>>>
>>>>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.
>>>
>>>This use case fell out very naturally for me while working on a
>>>website that
>>>uses detached objects. I ended up with a transient User object
>>>referencing
>>>a detached Country object, and, of course, when I called
>>>pm.makePersistent(user), I got an JDOUserException as I should
>>>have, per the
>>>spec as it stands right now.
>>>
>>>--matthew
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
Remove pm.attachCopy? (was: RE: RETRY: Transient instance referencing a detached instance? (was: Question about attachCopy, transient & detached instances))
Posted by "Matthew T. Adams" <ma...@xcalia.com>.
I like the convergence in the api, and I also like the suggestion to return
the root object(s) from makePersistent, as it increases symmetry.
Could attachCopy and makePersistent become one, just makePersistent? The
only difference in the proposal as you suggest, Craig, is the handling of
transient instances. attachCopy copies instances and makes the copies
persistent-new, whereas makePersistent just makes them persistent-new; all
other behavior is the same. If we got rid of attachCopy, in favor of
makePersistent, and changed makePersistent such that it returns the root
object(s) given, then the behavior is covered, except for attachCopy's copy
semantic for transient instances. The only difference in the API if we keep
attachCopy is the copy semantic for transient instances, which I don't think
is all that important.
Thoughts?
--matthew
>-----Original Message-----
>From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
>Sent: Sunday, October 16, 2005 12:26 PM
>To: JDO Expert Group; jdo-dev@db.apache.org
>Subject: Re: RETRY: Transient instance referencing a detached
>instance? (was: Question about attachCopy, transient &
>detached instances)
>
>
>Javadogs,
>
>I've reviewed this material and agree with the general conclusion,
>that we can add the ability to include detached objects in the
>closure of instances for both makePersistent and attachCopy.
>
>The spec as of today requires treating these three types of objects
>in the closure differently:
>
>persistent instances
>
>attachCopy throws an exception; makePersistent ignores them
>
>transient instances
>
>attachCopy copies them and creates persistent-new instances;
>makePersistent makes them persistent-new
>
>detached instances
>
>attachCopy copies them; makePersistent throws an exception
>
>Here's the change as I would propose it:
>
>persistent instances
>
>attachCopy ignores them; makePersistent ignores them
>
>transient instances
>
>attachCopy copies them and creates persistent-new instances;
>makePersistent makes them persistent-new
>
>detached instances
>
>attachCopy copies them; makePersistent copies them
>
>If we make this change, the behavior of makePersistent and attachCopy
>are more similar than today. The differences are in the treatment of
>transient instances and whether or not the root objects are returned.
>If we like, we can have makePersistent also return the root objects
>by making a source-compatible change to the signatures of
>makePersistent.
>
>Craig
>
>On Oct 5, 2005, at 11:59 AM, Matthew T. Adams wrote:
>
>> "Wes Biggs" <we...@tralfamadore.com> wrote in message
>> news:<ma...@jdo-experts.org>...
>>
>>> 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.
>>
>> This use case fell out very naturally for me while working on a
>> website that
>> uses detached objects. I ended up with a transient User object
>> referencing
>> a detached Country object, and, of course, when I called
>> pm.makePersistent(user), I got an JDOUserException as I should
>> have, per the
>> spec as it stands right now.
>>
>> --matthew
>>
>>
>>
>
>