db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cbeams <cbe...@gmail.com>
Subject Re: JDO 2.1 spec draft: designing default values for convenience in annotations
Date Thu, 09 Aug 2007 01:12:42 GMT

Thanks for the response.  A few clarifications below:

- Chris

On Aug 8, 2007, at 5:35 PM, Craig L Russell wrote:

> Hi Chris,
> On Aug 8, 2007, at 4:59 PM, cbeams wrote:
>> Having used the annotations in their evolving forms for the last  
>> several months, I and my fellow developers have gotten very used  
>> to typing:
>>     @Persistent(persistenceModifier = PERSISTENT,  
>> defaultFetchGroup = "true")
>>     private MyObject obj;
>> To the uninitiated, it seems rather redundant to be using an  
>> annotation named "@Persistent", and then have to pass in  
>> "PERSISTENT" again.  It would be nice if this were the default,  
>> and in the (in my experience) much less frequent cases of  
>> TRANSIENT/UNKNOWN/NONE, I'm free to configure away.
> The default for a field that normally persistent should be  
> persistent. What happens if you leave off the persistenceModifier?  
> JPOX should default it to PERSISTENT.

Right... however, as "MyObject" is a custom type of my own creation  
and implicitly subclassing only java.lang.Object, it is NOT by  
default persistent (see http://www.jpox.org/docs/1_2/types.html).   
This means that I must both specify @Persistent AND pass a  
"persistenceModifier=PERSISTENT" parameter.  This is where the  
redundancy comes in.  Someone familiar with annotations but not  
familiar with JDO would naturally expect to need only to annotate the  
field as @Persistent for it to become, well... persistent.  It is  
troubling that it is even possible to specify @Persistent on a field  
and have it still end up transient.

This annotation was originally named @Field, and when this was the  
case, it was perhaps more justifiable to have to pass the  
persistenceModifier=PERSISTENT... But when the very name of the  
annotation is "Persistent", it is unintuitive that the field may  
still remain transient based on a matrix of types that persistent by  

>> The same goes for defaultFetchGroup.  Granted, I'm building an  
>> application that relies heavily on detachment, thus I want  
>> everything in my DFG, but from an ease-of-use / reducing the  
>> learning-curve point of view, I'd like to consider introducing  
>> 'reasonable defaults' into the annotations, such that I can type
>>     @Persistent
>>     private MyObject obj;
>> and it will 'just work', whether I'm attached / detached, etc.  As  
>> I begin to optimize, and want to take things out of my DFG, I can  
>> configure that easily enough by passing defaultFetchGroup =  
>> "false", but at that point, I must care about it enough to figure  
>> it out, right?  (refer to hype in general about convention over  
>> configuration :-)
> Yes, in the case above if MyObject is by default persistent, you  
> should not need @Persistent, and it will default to @Persistent 
> (persistenceModifier = PERSISTENT, defaultFetchGroup = "false").  
> These are the same rules as xml. If you want the field in the DFG,  
> you need only type @Persistent(defaultFetchGroup = "true").

Again, MyObject is not by default persistent, so I'm stuck with the  
annotation verbosity.  In an application making use of a rich domain  
model, there will be many dozens of these kinds of declarations,  
because most types in the system will be custom types.

> But if the field were by default in the DFG, e.g.
> private Integer someValue;
> the default is @Persistent(persistenceModifier = PERSISTENT,  
> defaultFetchGroup = "true") Don't be misled by the default in the  
> annotation definition. The annotation default is to overcome a  
> deficiency in annotation processing. The real defaults are more  
> intelligent.
> Bottom line, the semantics of annotations should be identical to  
> xml. If not, please let us know.
>> While I'm on the topic, would it be unreasonable to make the  
>> 'detachable' parameter to @PersistenceCapable default to "true"?   
>> If this has performance implications (i.e.: extra bytecode has to  
>> get added during enhancement for objects that are detachable vs  
>> those that aren't), perhaps an option could be introduced to  
>> advise the implementation whether detachable is "true" or "false"  
>> by default.  I know for me, every single one of my calls to  
>> @PersistenceCapable includes a 'detachable="true"'.  This just  
>> feels punitive after a while.
> The issue here is that @Detachable classes are serialization- 
> incompatible with non-@Detachable classes. So I think the right  
> answer is to require you to specify it :-\

Understood.  So, perhaps my latter suggestion of a global option that  
specifies the default would be reasonable?  e.g.:   
javax.jdo.option.DetachableByDefault=true, or something to that  
effect.  The default for this option would be 'false' for backward- 
compat, of course.

>> I haven't given a great deal of thought to these suggested changes  
>> and their possible ramifications, but perhaps that's the benefit  
>> of being an 'ignorant user'...
> Au contraire. "Naive" users are often the best judges of the ease- 
> of-use of a specification.
>> I just know what I want from a convenience and ease-of-use point  
>> of view.  That said, one implication I can think of is that the  
>> annotations' default behavior would no longer map directly to that  
>> of the already-established XML metadata.  The second paragraph of  
>> the preamble to chapter 19 would have to change to accommodate  
>> this.  It currently reads:
>> 	The annotations described herein support the entire range of  
>> metadata that can be expressed using the xml format. Annotations  
>> have identical semantics to the corresponding xml metadata.
>> The semantics might be the same, but the defaults would be  
>> changing.  We would want to account for this in the spec, I'm sure.
> I think this is one of the most powerful parts of annotations.  
> Defaults are very important to get right.
> Craig
>> Food for thought, thanks much.
>> - Chris
>> Chris Beams
> 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