db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Thoughts about JDO 2.1 Annotation
Date Tue, 16 Jan 2007 00:53:08 GMT
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message