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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
Michael Bouschen [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
