|
Home > Archive > Apache JDO Project > August 2007 > Annotation enum : IdGeneratorStrategy
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Annotation enum : IdGeneratorStrategy
|
|
| Andy Jefferson 2007-08-09, 1:11 pm |
| JDO2 defines particular id generation=20
strategies ... "identity", "increment", "sequence", "uuid-string", "uuid-he=
x", "native".
Obviously implementations can define their own add-on strategies.
In XML we have free-form text and so people can just type=20
<field value-strategy=3D"auid"> and rely on the implementation providing on=
e=20
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=20
the "valueStrategy" name (and @DatastoreIdentity "strategy"), so they can=20
access implementations own variants too.
2. Make implementations use the @Extension to access these vendor add-on=20
strategies and use IdGeneratorStrategy.UNKNOWN (which is in the enum=20
currently)
I'm swaying towards 1 since its more consistent with XML specification. Any=
=20
opinions ?
=2D-=20
Andy =C2=A0(Java Persistent Objects - http://www.jpox.org)
| |
| Matthew T. Adams 2007-08-09, 1:11 pm |
| +1
-----Original Message-----
From: Andy Jefferson [mailto:andy@jpox.org]=20
Sent: Thursday, August 09, 2007 9:47 AM
To: jdo-dev@db.apache.org; JDO Expert Group
Subject: Annotation enum : IdGeneratorStrategy
JDO2 defines particular id generation=20
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=20
<field value-strategy=3D"auid"> and rely on the implementation providing =
one=20
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=20
the "valueStrategy" name (and @DatastoreIdentity "strategy"), so they =
can=20
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=20
currently)
I'm swaying towards 1 since its more consistent with XML specification. =
Any=20
opinions ?
--=20
Andy (Java Persistent Objects - http://www.jpox.org)
| |
| Craig L Russell 2007-08-09, 1:11 pm |
| | |
| cbeams 2007-08-09, 7:11 pm |
| 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)
| |
| Matthew T. Adams 2007-08-09, 7:11 pm |
| 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)
| |
| Andy Jefferson 2007-08-10, 1:11 am |
| > 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 "";
> }
If going for this case a "CUSTOM" value should be added to the enum (rather=
=20
than using UNKNOWN - which is for where you don't want one, maybe it should=
=20
be NONE instead of UNKNOWN), and when it is CUSTOM the user supplies=20
the "customValueStrategy". Similarly in @DatastoreIdentity "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.
Well the implementors of annotations in the JDK decided on this classic=20
restriction :-
"only primitive, String, Class, annotation, enum are permitted as the types=
of=20
the element in an annotation" meaning that you can't have an element with a=
n=20
interface type.
and we also can't "extend" an enum.
=2D-=20
Andy =A0(Java Persistent Objects - http://www.jpox.org)
| |
| cbeams 2007-08-10, 7:11 am |
| > Well the implementors of annotations in the JDK decided on this
> classic
> restriction :-
> "only primitive, String, Class, annotation, enum are permitted as
> the types of
> the element in an annotation" meaning that you can't have an
> element with an
> interface type.
> and we also can't "extend" an enum.
Ugh. Just confirmed this. Bummer.
In light of that restriction, my vote goes for the addition of an
IdGeneratorStrategy.CUSTOM label to be used in conjunction with a
customValueStrategy string element as mentioned below.
- Chris
P.S.: Is anybody talking about improving annotation semantics,
perhaps in the Java 7 timeline? There are multiple new JSR's
regarding annotations: 250, 305, 308, but no apparent effort to
rectify these issues we've been running into. I'd be interested to
hear if anyone's heard about any such effort.
On Aug 9, 2007, at 10:56 PM, Andy Jefferson wrote:
>
> If going for this case a "CUSTOM" value should be added to the enum
> (rather
> than using UNKNOWN - which is for where you don't want one, maybe
> it should
> be NONE instead of UNKNOWN), and when it is CUSTOM the user supplies
> the "customValueStrategy". Similarly in @DatastoreIdentity
> "strategy".
>
>
>
>
> --
> Andy (Java Persistent Objects - http://www.jpox.org)
| |
| Craig L Russell 2007-08-10, 1:11 pm |
| |
|
|
|
|