Prev: Is there any ActiveRecord implementation for java?
Next: CFP: PPPJ 2010 -- Principles and Practice of Programming in Java (Vienna, Sep 10)
From: Arved Sandstrom on 18 Dec 2009 20:27
david.karr wrote:
> Quite often databases will have columns that are stored as integers,
> but represent enumerated values. In object-relational mapping, it's a
> good idea to translate that integer value to the enumerated value it
> represents.
[ SNIP ]

It's an even better idea to store the enumeration "name" as a varchar.
Do you have that control or is it already past that point?

If the values are integers in the database, I would not consider
re-ordering enum constants at all. After all, once the tables that have
that integer column start being populated, are you going back and
re-writing them every time you change the order of enum constants? I
don't think so. And who cares what order the enum constants have? If you
do care then you are depending on the ordinal values, which is a form of
hard-coding.

AHS
From: david.karr on 18 Dec 2009 21:24
On Dec 18, 5:27 pm, Arved Sandstrom <dces...(a)hotmail.com> wrote:
> david.karr wrote:
> > Quite often databases will have columns that are stored as integers,
> > but represent enumerated values.  In object-relational mapping, it's a
> > good idea to translate that integer value to the enumerated value it
> > represents.
>
> [ SNIP ]
>
> It's an even better idea to store the enumeration "name" as a varchar.
> Do you have that control or is it already past that point?
>
> If the values are integers in the database, I would not consider
> re-ordering enum constants at all. After all, once the tables that have
> that integer column start being populated, are you going back and
> re-writing them every time you change the order of enum constants? I
> don't think so. And who cares what order the enum constants have? If you
> do care then you are depending on the ordinal values, which is a form of
> hard-coding.
>
> AHS

I cannot change the database at all, even adding tables or columns.
The enum values that are in the database will not change. We may
eventually add new enum values with different ordinal values.

Although integers are stored in the db, I need to map those to the
enum name on read. Mapping in the other direction isn't that bad, as
I can map to the particular enum value from the enum string out of the
box, and then get the column value mapping from the enum value.
From: John B. Matthews on 18 Dec 2009 22:53
In article
<24ebe868-e3b3-49f9-a23c-0c47a107d6fe(a)a32g2000yqm.googlegroups.com>,
"david.karr" <davidmichaelkarr(a)gmail.com> wrote:

> On Dec 18, 4:25 pm, EJP <esmond.not.p...(a)not.bigpond.com> wrote:
> > david.karr wrote:
> > > Can someone think of a better way to do this, that doesn't repeat
> > > the column values?
> >
> > Have each enum value enter itself on construction into a
> > Map<Integer, YourEnum> with its own ColumnValue as the key.
> >
> > Like Peter I cannot see the point of setColumnValue(), and the Map
> > would of course require the columnValue to be constant.
>
> Yes, you're right, there's no need for "setColumnValue()".
>
> Concerning the Map, I had already thought of that. That's the
> obvious way to do it. Now, how would you do it? I would assume
> you'd define a static Map in the enum type and have the constructor
> put itself into the map. The problem is, it doesn't appear to be
> possible to do that. It doesn't compile.

A static initializer works, as suggested in the "enum Color" discussion:

<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.9>

Here's a similar example that constructs a Map<Integer, Key>, where
Integer is a keyCode and Key is an enum:

<http://robotchase.svn.sourceforge.net/viewvc/robotchase/trunk/
src/org/gcs/robot/Key.java?revision=27&view=markup>

The mapping is persisted using java.util.prefs.Preferences rather than a
database, but the result is similar.

> What might work is implementing some sort of "super-map" that holds
> all the mappings for all enum types you implement, so the key would
> have to concatenate the class and the custom ordinal.

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
From: Lew on 18 Dec 2009 23:46
Peter Duniho wrote:
> I'm also a little confused by the "setColumnValue()" method, as it
> implies to me that there's the expectation of a mutable enum instance. I
> would normally expect an enum instance to be immutable. But that's
> probably just an artifact of my relative unfamiliarity with Java's
> implementation of enums.

You're right. The enum should be immutable, and the integer 'columnValue'
should be 'final'.

I prefer to use string values for this sort of thing, but the principle is the
same. You have 'getColumnValue()' (or 'toString()') as an instance method to
translate the enum value to an external representation, and
'fromColumnValue()' ('fromString()') as a static method to return the enum
value from the external representation.

--
Lew
From: Lew on 18 Dec 2009 23:51
Martin Gregorie wrote:
> On Sat, 19 Dec 2009 01:27:13 +0000, Arved Sandstrom wrote:
>
>> david.karr wrote:
>>> Quite often databases will have columns that are stored as integers,
>>> but represent enumerated values. In object-relational mapping, it's a
>>> good idea to translate that integer value to the enumerated value it
>>> represents.
>> [ SNIP ]
>>
>> It's an even better idea to store the enumeration "name" as a varchar.
>>
> Agreed - and hold the integer:name mapping as a separate table.

Or don't even bother with integers in the database at all, but just use the
VARCHAR value.

--
Lew
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Is there any ActiveRecord implementation for java?
Next: CFP: PPPJ 2010 -- Principles and Practice of Programming in Java (Vienna, Sep 10)