Re: Thoughts about JDO 2.1 Annotation

[Ilan Kirsh]

Hi Craig,

Thanks for your prompt response.

I understand the limitation of boolean attributes, therefore, I suggested to 
move from attribute to annotation.

This way we will have 3 options:
    (1) @Indexed or @Indexed(true)
    (2) @Indexed(false)
    (3) Not using @Indexed at all - which means implied

Regards,

Ilan

  ----- Original Message ----- 
  From: Craig L Russell 
  To: Ilan Kirsh 
  Cc: jdo-dev@db.apache.org ; JDO Expert Group 
  Sent: Tuesday, January 16, 2007 2:53 AM
  Subject: Re: Thoughts about JDO 2.1 Annotation


  Hi Ilan, 


  Thanks for your constructive comments. I've not yet had a detailed look at 
Andy's proposed annotations, and I'll consider your comments when I review them.


  I have thought about public @interface Indexed { boolean value() default 
true; } and there is an issue in general with using boolean annotations. If you 
don't define a default value for a property, then you must declare it each 
time. But if you define a default value, you cannot tell whether the compiler 
provided it as a default or the user declared it. So for me it makes sense to 
use String indexed() default ""; as Andy suggested.


  More later,


  Craig


  On Jan 15, 2007, at 4:16 PM, Ilan Kirsh wrote:


    Hi all,

    I just added Java 5.0 annotation support to ObjectDB, following the work 
that was contributed by Andy (http://issues.apache.org/jira/browse/JDO-403).
    Andy did a great job, but still there might be a little room for 
improvements. Following are suggestions that might be considered.

    1. Using simple annotations instead of complex attributes
    For instance:
        @PrimaryKey
    instead of:
        @Field(primaryKey=true)
    (or simply @Id as in JPA).

    And another example:
        @Embedded / @Embedded(false)
    Instead of:
        @Field(embedded="true") / @Field(embedded="false")
    which also solves the need to use boolean as string in order to get a third 
state, which doesn't look good.

    This could be done at least for the more common attributes.

    Also, maybe @Index should be defined without unique option, by:
        public @interface Indexed { boolean value() default true; }
    or maybe even by:
        public @interface Unique {}
    and simply used with:
        @Indexed
    Do we really need so many different methods to define a unique index?

    2. Discarding @Array, @Collection and @Map
    It seems logical to move the attributes of @Array, @Collection and @Map to 
@Element, @Key and @Value. The separation (whose origin is in the XML) is 
unclear to me.

    3. Merging all annotations to one package
    Good separation seems to be very difficult. For instance - @Index, which is 
currently in orm has both columns and fields as attributes. Fields are not 
related to orm - just columns. If the separation remains, at least moving 
@Index, @Indices, @Unique, @Uniques, @Element, @Key and @Value that contain 
also non orm information should be pulled out to the main package.

    4. Type attributes should be Class rather than String
    For instance, in Field:
        Class fieldType();
    instead of:
        String fieldType() default "";

    5. RecursionDepth
    Should be added somehow to the fields in @FetchGroup (and removed from 
@Field if unused).

    Regards,

    Ilan Kirsh
    ObjectDB Software
    http://www.objectdb.com




  Craig Russell

  Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

  408 276-5638 mailto:[EMAIL PROTECTED]

  P.S. A good JDO? O, Gasp!