db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Issue 135: Remove attachCopy from PersistenceManager
Date Tue, 01 Nov 2005 23:38:00 GMT

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);

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  
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 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!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message