+1! I really like this proposal from a user's perspective.
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, November 01, 2005 3:38 PM
>To: JDO Expert Group; [email protected]
>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:[EMAIL PROTECTED]
>P.S. A good JDO? O, Gasp!
>
>
