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 02:17:24 GMT
Hi Chris,

It is perfectly reasonable to have the annotation
>>>     @Persistent
>>>     private MyObject obj;
and have field obj actually be persistent.

The xml metadata is a bit unhelpful If you annotate
<class name="foo">
   <field name="obj"/>
...
</class>
I think that foo is transient because of defaults.

Let's see how to make this more helpful, both for xml and  
annotations. I don't want to make it more difficult for xml just  
because we fix annotations.

Craig

On Aug 8, 2007, at 6:12 PM, cbeams wrote:

> Craig,
>
> 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 default.
>
>>>
>>> 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!
>>
>

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