db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew T. Adams" <matt...@matthewadams.org>
Subject RE: Annotation enum : IdGeneratorStrategy
Date Thu, 09 Aug 2007 21:32:49 GMT
Homer:  [Gasp]  Computers can do that?!?!

I like this last suggestion.  I didn't know you could do that.  Shows how
much I know about annotations!  :)  Nice suggestion, Chris!

-----Original Message-----
From: cbeams [mailto:cbeams@gmail.com] 
Sent: Thursday, August 09, 2007 11:13 AM
To: jdo-dev@db.apache.org
Cc: JDO Expert Group
Subject: Re: Annotation enum : IdGeneratorStrategy

I really prefer the ease-of-use afforded by consistently using  
enums.  My options are just an auto-complete away.

As a perhaps lighter-weight variant on Andy's option (2) below, could  
we simply provide an alternative, string-based parameter to the  
annotation, such as 'customValueStrategy'?

     @Target({ElementType.FIELD, ElementType.METHOD})
     @Retention(RetentionPolicy.RUNTIME)
     public @interface Persistent
     {
         // ...
         IdGeneratorStrategy valueStrategy() default  
IdGeneratorStrategy.UNKNOWN;
         String customValueStrategy() default "";
     }

I imagine these two options would be mutually exclusive, or an  
additional label could be added to the IdGeneratorStrategy,  
'CUSTOM'.  The implementation would enforce that  
'customValueStrategy' can only be supplied when valueStrategy == CUSTOM.

All I really care about is that I can use language-level enums  
whenever I have an enumerated set of values to choose from.  I'm okay  
with things being slightly awkward if I'm doing something a little  
out of the norm, like using a custom strategy.


Another option could be to have IdGeneratorStrategy become a marker  
interface and then have the enum be defined as something like:

     public interface IdGeneratorStrategy {}

     public enum StandardIdGeneratorStrategy implements  
IdGeneratorStrategy
     {
         UNKNOWN,
         NATIVE,
         // ...
     };

This would allow implementations to supply custom id generators in a  
typesafe way:

     package org.jpox.annotations;
     public enum JPOXIdGeneratorStrategy implements IdGeneratorStrategy
     {
         AUID,
         // ...
     };

I like this latter approach, because it demonstrates very clearly  
that my usage is vendor-specific and non-portable.


On Aug 9, 2007, at 9:47 AM, Andy Jefferson wrote:

> JDO2 defines particular id generation
> strategies ... "identity", "increment", "sequence", "uuid-string",  
> "uuid-hex", "native".
> Obviously implementations can define their own add-on strategies.
>
> In XML we have free-form text and so people can just type
> <field value-strategy="auid"> and rely on the implementation  
> providing one
> called "auid".
> In Annotations they currently can't do this since it uses an enum.
>
>
> Two possible options
> 1. Remove IdGeneratorStrategy enum and just let people type in
> the "valueStrategy" name (and @DatastoreIdentity "strategy"), so  
> they can
> access implementations own variants too.
> 2. Make implementations use the @Extension to access these vendor  
> add-on
> strategies and use IdGeneratorStrategy.UNKNOWN (which is in the enum
> currently)
>
>
> I'm swaying towards 1 since its more consistent with XML  
> specification. Any
> opinions ?
>
> -- 
> Andy  (Java Persistent Objects - http://www.jpox.org)



Mime
View raw message