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 22:12:23 GMT
The enumeration example I have on the wiki (which I used with Cayenne
1.2) allowed for human-suitable names that differed from the actual
backend representation and allowed you to use localization for
different presentations (useful in a web application).  I'm not sure
if that would be applicable in your situation, though.  I wasn't even
really promoting that feature for a native Cayenne implementation, but
if there is a need for it ...


On Jan 17, 2008 3:20 PM, Kevin Menard <> wrote:
> On 1/17/08 9:47 AM, "Michael Gentry" <> wrote:
> > 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.
> Yes, what Ari mentioned sounds nice.
> I could see value in "composite" enums as well, though.  I can't think of a
> better term, but they're basically enums with fields that could then be
> mapped to DB columns.
> For example, we use FedEx to process our shipments.  The FedEx API has codes
> for each service, but the codes are not really in a suitable form for a
> customer.  So, we store the code and the textual description as two columns
> in the table.  The set of values is largely fixed, but as we offer new
> shipping methods (e.g., we started offering USPS), we added more rows to the
> table.
> It'd be nice if there were a way to map the rows in that table as enum
> instances (Java5 or otherwise) automatically.  The code could be
> considerably simplified (I'm a big fan of switching with Java5 enums), but
> maintain the flexibility of a DB backend.
> I'm acutely aware that this is likely a pipedream though, given the invasive
> nature of it all.
> --
> Kevin

View raw message