Re: JDO 2.1 spec draft: designing default values for convenience in annotations
Web Server forum
Back To The Forum Home!Search!Private Messaging System

Web Server Talk Web Server Talk > Web Servers reviews > Apache Server configuration support > Apache JDO Project > Re: JDO 2.1 spec draft: designing default values for convenience in annotations




  Last Thread   Next Thread Next
  Show Printable Version Email this Page Subscribe to this Thread      Post New Thread    Post A Reply      

    Re: JDO 2.1 spec draft: designing default values for convenience in annotations  
cbeams


View Ip Address Report This Message To A Moderator Edit/Delete Message


 
08-09-07 12:11 AM

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 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 :-)

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.

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'... 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.

Food for thought, thanks much.

- Chris

Chris Beams





[ Post a follow-up to this message ]



    Sponsored Links  




 





   All times are GMT. The time now is 06:33 AM.      Post New Thread    Post A Reply      
  Last Thread   Next Thread Next


Most Popular forums 

Forum Jump:
Rate This Thread:

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are ON
[IMG] code is OFF
 
Medical and Health forum | Computer Games Reviews | Graphics design forum

Back To The Top
Home | Usercp | Faq | Register