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/11/02 00:38:00 UTC
Issue 135: Remove attachCopy from PersistenceManager
Javadogs,
Please comment on this proposal.
There are so few differences between makePersistent and attachCopy,
it's confusing. The only significant differences between the APIs is
in the treatment of transient instances. MakePersistent makes
transient instances transition to persistent-new; attachCopy copies
transient instances.
The proposal is to remove attachCopy, change the signature of
makePersistent and makePersistentAll to return the instance(s), and
add a method to JDOHelper.
The semantics of makePersistent change slightly from the
specification. Currently, detached instances in the object graph
cause an exception to be thrown. With this change, detached instances
are located in the persistent cache and any dirty fields are applied
to the persistent instance.
With this change, there is no standard way to attach the same object
graph to multiple persistence managers. So a method is added to
JDOHelper that copies a complete object graph so the copies can be
attached to multiple persistence managers.
Instead of:
Object[ ] attached1 = pm.attachCopy(graph);
Object[ ] attached2 = pm.attachCopy(graph);
use:
Object[ ] copies = JDOHelper.shallowCopy(graph, false);
Object[ ] attached1 = pm.makePersistentAll(copies);
Object[ ] attached2 = pm.makePersistentAll(copies);
The signatures of shallowCopy are:
Object shallowCopy(Object original, boolean copyTransientFields);
Collection shallowCopyAll(Collection original, boolean
copyTransientFields);
Object[ ] shallowCopy(Object[ ] original, boolean copyTransientFields);
The copyTransientFields parameter specifies whether to copy the
transient fields of detached and transient instances. True requires
that the JDOHelper be given security privileges to allow reflective
copy. Non-binary-compatible implementations also require security
privileges. Binary-compatible implementations will use the support
for PersistenceCapable to copy the fields.
Support for deep copies is left to the implementation, as there is no
standard way to deep copy.
Craig
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!
Re: Issue 135: Remove attachCopy from PersistenceManager
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi,
On Nov 2, 2005, at 7:30 AM, Michael Bouschen wrote:
> Hi Jörg,
>
> good catch! Yes, the examples are meant to use two different
> PersistenceManagers pm1 and pm2.
>
> I think JDOHelper.shallowCopy would work for any instance of a
> persistence capable class, not only for detached instances.
>
The semantics of JDOHelper.shallowCopyAll would be to make an object
graph suitable for attachment. So there would be a copy made of
transient and detached instances but persistent instances would not
be copied.
Perhaps shallowCopyAll isn't the right name since we don't shallow
copy persistent instances. Maybe something like copyForAttachment or
something like it.
>
> Regards Michael
Regards,
Craig
>
>
>> Craig L Russell schrieb:
>>
>>> With this change, there is no standard way to attach the same
>>> object graph to multiple persistence managers. So a method is
>>> added to JDOHelper that copies a complete object graph so the
>>> copies can be attached to multiple persistence managers.
>>>
>>> Instead of:
>>> Object[ ] attached1 = pm.attachCopy(graph);
>>> Object[ ] attached2 = pm.attachCopy(graph);
>>>
>>> use:
>>> Object[ ] copies = JDOHelper.shallowCopy(graph, false);
>>> Object[ ] attached1 = pm.makePersistentAll(copies);
>>> Object[ ] attached2 = pm.makePersistentAll(copies);
>>>
>> There is only one and the same persistence manager being used in
>> these examples, shouldn't it be more like:
>> Instead of:
>> Object[ ] attached1 = pm1.attachCopy(graph);
>> Object[ ] attached2 = pm2.attachCopy(graph);
>> use:
>> Object[ ] copies = JDOHelper.shallowCopy(graph, false);
>> Object[ ] attached1 = pm1.makePersistentAll(copies);
>> Object[ ] attached2 = pm2.makePersistentAll(copies);
>> BTW, is JDOHelper.shallowCopy() supposed to work only on a
>> detached graph or on any persistence capable object?
>> Regards,
>> Jörg
>>
>
>
> --
> Michael Bouschen Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de http://www.tech.spree.de/
> Tel.:++49/30/235 520-33 Buelowstr. 66
> Fax.:++49/30/2175 2012 D-10783 Berlin
>
Re: Issue 135: Remove attachCopy from PersistenceManager
Posted by Michael Bouschen <mb...@spree.de>.
Hi Jörg,
good catch! Yes, the examples are meant to use two different
PersistenceManagers pm1 and pm2.
I think JDOHelper.shallowCopy would work for any instance of a
persistence capable class, not only for detached instances.
Regards Michael
> Craig L Russell schrieb:
>
>> With this change, there is no standard way to attach the same object
>> graph to multiple persistence managers. So a method is added to
>> JDOHelper that copies a complete object graph so the copies can be
>> attached to multiple persistence managers.
>>
>> Instead of:
>> Object[ ] attached1 = pm.attachCopy(graph);
>> Object[ ] attached2 = pm.attachCopy(graph);
>>
>> use:
>> Object[ ] copies = JDOHelper.shallowCopy(graph, false);
>> Object[ ] attached1 = pm.makePersistentAll(copies);
>> Object[ ] attached2 = pm.makePersistentAll(copies);
>
>
> There is only one and the same persistence manager being used in these
> examples, shouldn't it be more like:
>
> Instead of:
> Object[ ] attached1 = pm1.attachCopy(graph);
> Object[ ] attached2 = pm2.attachCopy(graph);
>
> use:
> Object[ ] copies = JDOHelper.shallowCopy(graph, false);
> Object[ ] attached1 = pm1.makePersistentAll(copies);
> Object[ ] attached2 = pm2.makePersistentAll(copies);
>
> BTW, is JDOHelper.shallowCopy() supposed to work only on a detached
> graph or on any persistence capable object?
>
> Regards,
> Jörg
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
Re: Issue 135: Remove attachCopy from PersistenceManager
Posted by Jörg von Frantzius <jo...@artnology.com>.
Craig L Russell schrieb:
> With this change, there is no standard way to attach the same object
> graph to multiple persistence managers. So a method is added to
> JDOHelper that copies a complete object graph so the copies can be
> attached to multiple persistence managers.
>
> Instead of:
> Object[ ] attached1 = pm.attachCopy(graph);
> Object[ ] attached2 = pm.attachCopy(graph);
>
> use:
> Object[ ] copies = JDOHelper.shallowCopy(graph, false);
> Object[ ] attached1 = pm.makePersistentAll(copies);
> Object[ ] attached2 = pm.makePersistentAll(copies);
There is only one and the same persistence manager being used in these
examples, shouldn't it be more like:
Instead of:
Object[ ] attached1 = pm1.attachCopy(graph);
Object[ ] attached2 = pm2.attachCopy(graph);
use:
Object[ ] copies = JDOHelper.shallowCopy(graph, false);
Object[ ] attached1 = pm1.makePersistentAll(copies);
Object[ ] attached2 = pm2.makePersistentAll(copies);
BTW, is JDOHelper.shallowCopy() supposed to work only on a detached
graph or on any persistence capable object?
Regards,
Jörg
--
__________________________________________________________
Dipl.-Inf. Jörg von Frantzius | artnology GmbH
| Milastr. 4
Tel +49 (0)30 4435 099 26 | 10437 Berlin
Fax +49 (0)30 4435 099 99 | http://www.artnology.com
_______________________________|__________________________
Re: Issue 135: Remove attachCopy from PersistenceManager
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Michael,
On Nov 2, 2005, at 7:13 AM, Michael Bouschen wrote:
> Hi Craig,
>
> +1!
>
> The current spec has a section called "Attaching Instances" (at the
> end of 12.6.8 Detaching and attaching instances). I assume this
> section will then describe how to use makePersistent to attach
> detached instances, correct?
That's correct. We also need to think about whether we change or keep
the name of the instance callbacks for attach. I think using the term
"attach" to describe the behavior of makePersistent applied to
detached instances is ok and we can keep the method names.
We also need to define what happens to transient fields of detached
instances when we attach them. Do they get copied or ignored? The
spec would lead me to believe that they are ignored. And if they are
ignored, is there a reason to optionally copy them with the
shallowCopyAll method?
Craig
>
> A minor remark: I think the shallowCopy method taking an array of
> objects should be called shallowCopyAll:
> Object[] shallowCopyAll(Object[] original, boolean
> copyTransientFields)
>
> Regards Michael
>
>
>> Javadogs,
>> Please comment on this proposal.
>> There are so few differences between makePersistent and
>> attachCopy, it's confusing. The only significant differences
>> between the APIs is in the treatment of transient instances.
>> MakePersistent makes transient instances transition to persistent-
>> new; attachCopy copies transient instances.
>> The proposal is to remove attachCopy, change the signature of
>> makePersistent and makePersistentAll to return the instance(s),
>> and add a method to JDOHelper. The semantics of makePersistent
>> change slightly from the specification. Currently, detached
>> instances in the object graph cause an exception to be thrown.
>> With this change, detached instances are located in the persistent
>> cache and any dirty fields are applied to the persistent instance.
>> With this change, there is no standard way to attach the same
>> object graph to multiple persistence managers. So a method is
>> added to JDOHelper that copies a complete object graph so the
>> copies can be attached to multiple persistence managers.
>> Instead of:
>> Object[ ] attached1 = pm.attachCopy(graph);
>> Object[ ] attached2 = pm.attachCopy(graph);
>> use:
>> Object[ ] copies = JDOHelper.shallowCopy(graph, false);
>> Object[ ] attached1 = pm.makePersistentAll(copies);
>> Object[ ] attached2 = pm.makePersistentAll(copies);
>> The signatures of shallowCopy are:
>> Object shallowCopy(Object original, boolean copyTransientFields);
>> Collection shallowCopyAll(Collection original, boolean
>> copyTransientFields);
>> Object[ ] shallowCopy(Object[ ] original, boolean
>> copyTransientFields);
>> The copyTransientFields parameter specifies whether to copy the
>> transient fields of detached and transient instances. True
>> requires that the JDOHelper be given security privileges to allow
>> reflective copy. Non-binary-compatible implementations also
>> require security privileges. Binary-compatible implementations
>> will use the support for PersistenceCapable to copy the fields.
>> Support for deep copies is left to the implementation, as there is
>> no standard way to deep copy.
>> Craig
>> 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!
>>
>
>
> --
> Michael Bouschen Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de http://www.tech.spree.de/
> Tel.:++49/30/235 520-33 Buelowstr. 66
> Fax.:++49/30/2175 2012 D-10783 Berlin
>
Re: Issue 135: Remove attachCopy from PersistenceManager
Posted by Michael Bouschen <mb...@spree.de>.
Hi Craig,
+1!
The current spec has a section called "Attaching Instances" (at the end
of 12.6.8 Detaching and attaching instances). I assume this section will
then describe how to use makePersistent to attach detached instances,
correct?
A minor remark: I think the shallowCopy method taking an array of
objects should be called shallowCopyAll:
Object[] shallowCopyAll(Object[] original, boolean copyTransientFields)
Regards Michael
> Javadogs,
>
> Please comment on this proposal.
>
> There are so few differences between makePersistent and attachCopy, it's
> confusing. The only significant differences between the APIs is in the
> treatment of transient instances. MakePersistent makes transient
> instances transition to persistent-new; attachCopy copies transient
> instances.
>
> The proposal is to remove attachCopy, change the signature of
> makePersistent and makePersistentAll to return the instance(s), and add
> a method to JDOHelper.
>
> The semantics of makePersistent change slightly from the specification.
> Currently, detached instances in the object graph cause an exception to
> be thrown. With this change, detached instances are located in the
> persistent cache and any dirty fields are applied to the persistent
> instance.
>
> With this change, there is no standard way to attach the same object
> graph to multiple persistence managers. So a method is added to
> JDOHelper that copies a complete object graph so the copies can be
> attached to multiple persistence managers.
>
> Instead of:
> Object[ ] attached1 = pm.attachCopy(graph);
> Object[ ] attached2 = pm.attachCopy(graph);
>
> use:
> Object[ ] copies = JDOHelper.shallowCopy(graph, false);
> Object[ ] attached1 = pm.makePersistentAll(copies);
> Object[ ] attached2 = pm.makePersistentAll(copies);
>
> The signatures of shallowCopy are:
> Object shallowCopy(Object original, boolean copyTransientFields);
> Collection shallowCopyAll(Collection original, boolean copyTransientFields);
> Object[ ] shallowCopy(Object[ ] original, boolean copyTransientFields);
>
> The copyTransientFields parameter specifies whether to copy the
> transient fields of detached and transient instances. True requires that
> the JDOHelper be given security privileges to allow reflective copy.
> Non-binary-compatible implementations also require security privileges.
> Binary-compatible implementations will use the support for
> PersistenceCapable to copy the fields.
>
> Support for deep copies is left to the implementation, as there is no
> standard way to deep copy.
>
> Craig
>
>
> 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!
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
RE: Issue 135: Remove attachCopy from PersistenceManager
Posted by "Matthew T. Adams" <ma...@xcalia.com>.
+1! I really like this proposal from a user's perspective.
>-----Original Message-----
>From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]
>Sent: Tuesday, November 01, 2005 3:38 PM
>To: JDO Expert Group; jdo-dev@db.apache.org
>Subject: Issue 135: Remove attachCopy from PersistenceManager
>
>
>Javadogs,
>
>Please comment on this proposal.
>
>There are so few differences between makePersistent and attachCopy,
>it's confusing. The only significant differences between the APIs is
>in the treatment of transient instances. MakePersistent makes
>transient instances transition to persistent-new; attachCopy copies
>transient instances.
>
>The proposal is to remove attachCopy, change the signature of
>makePersistent and makePersistentAll to return the instance(s), and
>add a method to JDOHelper.
>
>The semantics of makePersistent change slightly from the
>specification. Currently, detached instances in the object graph
>cause an exception to be thrown. With this change, detached instances
>are located in the persistent cache and any dirty fields are applied
>to the persistent instance.
>
>With this change, there is no standard way to attach the same object
>graph to multiple persistence managers. So a method is added to
>JDOHelper that copies a complete object graph so the copies can be
>attached to multiple persistence managers.
>
>Instead of:
>Object[ ] attached1 = pm.attachCopy(graph);
>Object[ ] attached2 = pm.attachCopy(graph);
>
>use:
>Object[ ] copies = JDOHelper.shallowCopy(graph, false);
>Object[ ] attached1 = pm.makePersistentAll(copies);
>Object[ ] attached2 = pm.makePersistentAll(copies);
>
>The signatures of shallowCopy are:
>Object shallowCopy(Object original, boolean copyTransientFields);
>Collection shallowCopyAll(Collection original, boolean
>copyTransientFields);
>Object[ ] shallowCopy(Object[ ] original, boolean copyTransientFields);
>
>The copyTransientFields parameter specifies whether to copy the
>transient fields of detached and transient instances. True requires
>that the JDOHelper be given security privileges to allow reflective
>copy. Non-binary-compatible implementations also require security
>privileges. Binary-compatible implementations will use the support
>for PersistenceCapable to copy the fields.
>
>Support for deep copies is left to the implementation, as there is no
>standard way to deep copy.
>
>Craig
>
>
>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!
>
>