db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilan Kirsh <ki...@objectdb.com>
Subject Thoughts about JDO 2.1 Annotation
Date Tue, 16 Jan 2007 00:16:19 GMT
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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message