Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Date: Tue, 16 Jan 2007 03:01:52 +0200
From: Ilan Kirsh <kirsh@objectdb.com>
Subject: Re: Thoughts about JDO 2.1 Annotation
To: Craig L Russell <Craig.Russell@Sun.COM>
Cc: jdo-dev@db.apache.org, JDO Expert Group <jdo-experts-ext@Sun.COM>
Reply-to: Ilan Kirsh <kirsh@objectdb.com>
Message-id: <004401c73909$feaf78f0$0500000a@ILANC>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="----=_NextPart_000_003C_01C7391A.AC6D36C0"

------=_NextPart_000_003C_01C7391A.AC6D36C0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

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 -----=20
  From: Craig L Russell=20
  To: Ilan Kirsh=20
  Cc: jdo-dev@db.apache.org ; JDO Expert Group=20
  Sent: Tuesday, January 16, 2007 2:53 AM
  Subject: Re: Thoughts about JDO 2.1 Annotation


  Hi Ilan,=20


  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=3Dtrue)
    (or simply @Id as in JPA).

    And another example:
        @Embedded / @Embedded(false)
    Instead of:
        @Field(embedded=3D"true") / @Field(embedded=3D"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:Craig.Russell@sun.com

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


------=_NextPart_000_003C_01C7391A.AC6D36C0--