db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilan Kirsh <ki...@objectdb.com>
Subject Re: Thoughts about JDO 2.1 Annotation
Date Tue, 16 Jan 2007 01:01:52 GMT
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



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


  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:
    instead of:
    (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:
    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).


    Ilan Kirsh
    ObjectDB Software

  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