enums

[Adam Hardy <ad...@cyberspaceroad.org>]

Hello All,

I'm making good use of the enum handling that is available in OpenJPA, which is 
a very welcome advance over the persistence framework I was using last.

I see that I can configure my mappings to use either EnumType.ORDINAL or STRING 
and I'm a little concerned that this is slightly restrictive, since the use of 
ORDINAL more or less compels me to keep my database data inline with my code, 
which may not be possible.

On the one hand, a probable irritant would be that inexperienced developers may 
add elements to the enum and mess up any existing data in the DB - presumably 
this would be easy to catch though.

On the other hand, there might be a need to code enums to fit existing data and 
that could require large numbers of unused elements as padding - which would not 
be too good.

Is this configuration option part of the EJB3 standard?

I would prefer to code my enums to use the database values:

public enum CodeType
{
     NOT_USED(0),
     SYSTEM(1),
     FUNCTION(2);

     private int dbValue;

     CodeType(int newValue) { this.dbValue = newValue; }

     public int toInteger() { return this.dbValue; }
}


Is there any plan for the future to incorporate this EnumType configuration?

Also, I have been searching the OpenJPA code base to ascertain how OpenJPA 
recognises an enum when mapping data to such a field. I can't find the code - 
could someone point me to it or give me a hint?

Thanks
Adam

Re: enums

[Adam Hardy <ad...@cyberspaceroad.org>]

Patrick Linskey on 03/01/08 06:54, wrote:
>> I see that I can configure my mappings to use either EnumType.ORDINAL or
>> STRING and I'm a little concerned that this is slightly restrictive, since
>> the use of ORDINAL more or less compels me to keep my database data inline
>> with my code, which may not be possible.
>> 
>> Is this configuration option part of the EJB3 standard?
> The JPA 1 spec only discusses ordinal- and string-based options. In the past,
> we have discussed something similar to OpenJPA's externalization features for
> inclusion in a future JPA release; this could let you move the code for
> specifying the DB value out of the enum altogether and essentially into
> mapping data. I believe that it would be possible to use OpenJPA's
> externalization features on an enum field currently, although I'm not sure if
> we have any test suites for that configuration.

So the externalization feature would essentially map the DB value to the Enum 
ordinal?

I think it would be disadvantageous to adopt custom OpenJPA features unless they
were likely to be included in the spec in the future. A value-based strategy for 
Enums is a must-have for use on projects with existing databases. With those 2 
points in mind, its absence more or less pushes you back to using public final 
statics.

>> Also, I have been searching the OpenJPA code base to ascertain how OpenJPA 
>> recognises an enum when mapping data to such a field. I can't find the code
>> - could someone point me to it or give me a hint?
> 
> I think that AnnotationPersistenceMappingParser.parseEnumerated() is probably
> the place to start. I found this by searching for usages of EnumValueHandler
> (the thing responsible for enums).

OK, great. Found it.

if ("java.lang.Enum".equals(type.getSuperclass().getName()))


Adam

Re: enums

[Patrick Linskey <pl...@gmail.com>]

Hi,

> Is this configuration option part of the EJB3 standard?

The JPA 1 spec only discusses ordinal- and string-based options. In
the past, we have discussed something similar to OpenJPA's
externalization features for inclusion in a future JPA release; this
could let you move the code for specifying the DB value out of the
enum altogether and essentially into mapping data. I believe that it
would be possible to use OpenJPA's externalization features on an enum
field currently, although I'm not sure if we have any test suites for
that configuration.

> Also, I have been searching the OpenJPA code base to ascertain how OpenJPA
> recognises an enum when mapping data to such a field. I can't find the code -
> could someone point me to it or give me a hint?

I think that AnnotationPersistenceMappingParser.parseEnumerated() is
probably the place to start. I found this by searching for usages of
EnumValueHandler (the thing responsible for enums).

-Patrick

On Jan 2, 2008 5:13 PM, Adam Hardy <ad...@cyberspaceroad.org> wrote:
> Hello All,
>
> I'm making good use of the enum handling that is available in OpenJPA, which is
> a very welcome advance over the persistence framework I was using last.
>
> I see that I can configure my mappings to use either EnumType.ORDINAL or STRING
> and I'm a little concerned that this is slightly restrictive, since the use of
> ORDINAL more or less compels me to keep my database data inline with my code,
> which may not be possible.
>
> On the one hand, a probable irritant would be that inexperienced developers may
> add elements to the enum and mess up any existing data in the DB - presumably
> this would be easy to catch though.
>
> On the other hand, there might be a need to code enums to fit existing data and
> that could require large numbers of unused elements as padding - which would not
> be too good.
>
> Is this configuration option part of the EJB3 standard?
>
> I would prefer to code my enums to use the database values:
>
> public enum CodeType
> {
>      NOT_USED(0),
>      SYSTEM(1),
>      FUNCTION(2);
>
>      private int dbValue;
>
>      CodeType(int newValue) { this.dbValue = newValue; }
>
>      public int toInteger() { return this.dbValue; }
> }
>
>
> Is there any plan for the future to incorporate this EnumType configuration?
>
> Also, I have been searching the OpenJPA code base to ascertain how OpenJPA
> recognises an enum when mapping data to such a field. I can't find the code -
> could someone point me to it or give me a hint?
>
> Thanks
> Adam
>



-- 
Patrick Linskey
202 669 5907