db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <Craig.Russ...@Sun.COM>
Subject Re: Detachment contract
Date Wed, 13 Jul 2005 23:02:44 GMT
Hi Geoff,

Thanks for the feedback.

On Jul 13, 2005, at 12:56 PM, Geoff hendrey wrote:

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

I'm not sold on the idea that we should make a user api out of these.  
We have survived the past 5 years without making this internal state  
visible, and I personally never heard anyone asking for it.

I don't believe that requiring the State Manager to track loaded and  
modified fields violates the Law of Demeter (of which I am a huge  
fan, by the way). It is specifically *not* the responsibility or the  
concern of the Persistence Capable instance to know whether a field  
is loaded or modified. It *is* the responsibility of the State  
Manager to know this and to enforce the policy of the JDO  
implementation. In fact, the way the PC/SM contract is written, the  
PC doesn't know which fields are loaded.

However, there is a valid reason for making the information standard  
when it is being externalized for detachment. The PC must be  
responsible for this information while detached. But it's arguably  
not the most efficient  way to have the State Manager handle it, and  
it's not even required for the State Manager to keep the information  
in this form until externalization.

So I would be against the requirement to have the State Manager track  
loaded and modified fields using this technique. And against the  
requirement to expose this state to user code.

Others?

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

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!


Mime
View raw message