Re: Thoughts about JDO 2.1 Annotation

[Craig L Russell]

Hi Ilan,






More later,

Craig

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

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.

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


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


3. Merging all annotations to one package


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

5. RecursionDepth


Regards,

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

which also solves the need to use boolean as string in order to get a third state, which doesn't look good. 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. 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. Should be added somehow to the fields in @FetchGroup (and removed from @Field if unused).

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!

smime.p7s
Description: S/MIME cryptographic signature