Basically issue is simple: How to store enum values into database. Sounds
simple, but when going after robust solution, then problems start to
appear.
Some approaches,
- Plenty of manual coding for each enumeration
* not generic
- Storing enum value names
* not robust, changes when enum names are changed
- Storing ordinal values
* not robust, changes when new enum values are added
Thus those approaches won't do the trick.
One potential solution could be something like
http://www.javaspecialists.co.za/archive/Issue113.html
But is there other alternatives?
> Basically issue is simple: How to store enum values into database. Sounds
> simple, but when going after robust solution, then problems start to
> appear.
That's rather putting the code before the database. Your enum values are
what database textbooks will refer to as domains. Domains can be
simulated in SQL with a populated table that doesn't change.
> Some approaches,
> - Plenty of manual coding for each enumeration
> * not generic
> - Storing enum value names
> * not robust, changes when enum names are changed
If you change the names you break source compatibility.
> - Storing ordinal values
> * not robust, changes when new enum values are added
If you change the ordinals you break binary compatibility.
If you must allow these things to change, without disrupting existing
data, then I think you want an extra layer of indirection. Expose the
enum in the API, and introduce a new type for the database. Because the
new type represents one of a fixed number of possibilities, an enum is
the obvious choice. But you don't have to change you implementation
until the separation is actually necessary.
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/