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 Re: JDO 2.1 spec draft: designing default values for convenience in annotations
Date Thu, 09 Aug 2007 00:35:18 GMT
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.
> 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").

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  

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 :-\
> 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.

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

View raw message