db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff hendrey <geoff_hend...@yahoo.com>
Subject Re: Detachment contract
Date Wed, 13 Jul 2005 19:56:04 GMT
<AMEN>
> The jdoDetachedState is an Object[ ] that consists
> of:
> 
> {
> Object objectId,
> Object version,
> BitSet loadedFields,
> BitSet modifiedFields
> }
</AMEN>

I also think it would be a nice improvement to make
loadedFields and modifiedFields accessible and useable
for non-detached classes. It's in good keeping with
Law of Demeter to keep this information as close to
the source as possible, instead of forcing the
StateManager  to track it.

We'd need to add jdoGetLoadedFields() and
jdoGetModifiedFields(). 

Or is there some reason this wouldn't work or doesn't
make sense?

-geoff





> The enhancer implements
> 
> Object jdoGetVersion() {
>    if (jdoStateManager != null) return
> jdoStateManager.getVersion(this);
>    try {
>      return (jdoDetachedState ==
> null)?null:jdoDetachedState[1];
>    } catch (Exception ex) {
>      throw new JDOFatalInternalException(msg.msg 
> ("EXC_IllegalDetachedState", ex);
>    }
> }
> 
> Object jdoGetObjectId() {
>    if (jdoStateManager != null) return
> jdoStateManager.getObjectId 
> (this);
>    try {
>      return (jdoDetachedState ==
> null)?null:jdoDetachedState[0];
>    } catch (Exception ex) {
>      throw new JDOFatalInternalException(msg.msg 
> ("EXC_IllegalDetachedState", ex);
>    }
> }
> 
> PersistenceManager flags determine the behavior for
> detachment,  
> regardless of whether the detachment is due to
> serialization or  
> explicit detachCopy.
> 
> get/setDetachmentOptions(int flags). The standard
> values are:
> public final static DETACH_LOAD_FIELDS
> public final static DETACH_UNLOAD_FIELDS
> 
> The LOAD_FIELDS flag specifies that the fetch plan
> in effect at the  
> time the object is detached determines the fields
> that must be loaded  
> (fetched from the datastore and marked as loaded) in
> the detached  
> instances. If this flag is not set, then the fields
> in the fetch plan  
> might be loaded or not depending on when the
> instances were fetched.
> 
> The UNLOAD_FIELDS flag specifies that the fetch plan
> in effect at the  
> time the object is detached determines the fields
> that must be  
> unloaded (set to their Java default values and
> marked as not loaded)  
> in the detached instances. If this flag is not set,
> then the fields  
> not in the fetch plan might be loaded or not
> depending on when the  
> instances were fetched.
> 
> Detachable classes that implement writeObject and
> readObject pose a  
> problem. The JVM standard serialization will include
> the  
> jdoDetachedState field because it is known to the
> VM. If the  
> writeObject delegates to the standard, this is fine.
> If not, the  
> jdoDetachedState field will not be written. So the
> enhancer checks  
> that the user's writeObject delegates to the
> out.defaultWriteObject()  
> and if it does not, inserts a call to write the
> jdoDetachedState  
> instance ahead of the rest of the object in the
> output stream. The  
> readObject method is similarly changed to read the
> state of the  
> jdoDetachedState field.
> 
> Similarly, if the class implements Externalizable,
> the enhancer adds  
> the code to the readExternal and writeExternal
> methods to handle the  
> jdoDetachedState field.
> 
> The jdoFlags value DETACHED is not used and will be
> removed from the  
> interface.
> 
> 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!
> 
> 



		
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
 

Mime
View raw message