cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Gentry" <>
Subject Re: Enum best practices
Date Thu, 17 Jan 2008 14:47:19 GMT
Ari, I was going to mention on the other thread (with Kevin) that it
would be nice if you could map the enumerated values in Cayenne
Modeler.  I believe Andrus even mentioned keeping the mapping in the
XML files, too.  The modeler could generate the code for the enums,
too, as you said.  This would free the user from having to write the
boilerplate code themselves.  I still see needing two types of
enumerations -- integer and string based values.  I can't really see
the need for floating point values at this time.


On Jan 16, 2008 6:01 PM, Aristedes Maniatis <> wrote:
> On 17/01/2008, at 9:32 AM, Kevin Menard wrote:
> > That's largely what I'm trying to avoid.  I don't want a bunch of
> > integer
> > values that have no meaning without the corresponding Java code.  I
> > suppose
> > SQL comments are one way to go or external documentation, but each
> > has its
> > own set of downsides.
> 1. Use VARCHAR instead and use meaningful names: "hold", "cancelled",
> etc. Not an approach I'd take, but an option.
> 2. I've been meaning to work on modeler docs for so long now. I've
> even got some code written for this, but not nearly done. [1]
> My point is that this enumerated field approach (as opposed to a
> related table) should only be used if the meaning is tied in deeply to
> the code (eg. cancelled invoices are removed from profit and loss
> calculations automatically by the system). So it is inevitable that
> the meaning is embedded within Java. The trick is to make sure it is
> clearly and simply documented. And that you can't assign a value of 10
> to the status field when they only go to 9.
> What would be really cool would be the ability within the modeler to
> define an enumeration which is attached to an attribute. You would
> define the values and names. Cayenne would then create the enum class
> with cgen. Then the model describes the complete picture and many more
> people would use enums instead of arbitrary integer values. Right now
> enums are a bit boring to create (I've got one enum attribute in a
> project I work on).
> [1]
> Ari
> -------------------------->
> ish
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001   fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

View raw message