Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (athena.apache.org: domain of blacknext@gmail.com
 designates 64.233.162.233 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=ejo2khtM/x9Kc4ucFjMwJ+DPwa6Lt7NzN9gpGP9yXOMVwNxerMjy6Q0ztS7GR6tVQJtGVLTj+JnATUHMB45QcTGRA9ScMwRWDVnl31DFbVFkEWirGSrV8iYrATF14HEcx+DX973ZKMe1KhVaY+MpNAHtWrx2OyKVHSGRjdQZhQ8=
Message-ID: <f65b8ae30801171412w7944cbb7o4b3bf6b9b5a26359@mail.gmail.com>
Date: Thu, 17 Jan 2008 17:12:23 -0500
From: "Michael Gentry" <blacknext@gmail.com>
To: user@cayenne.apache.org
Subject: Re: Enum best practices
In-Reply-To: <C3B522CC.BC1E%kmenard@servprise.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <f65b8ae30801170647h9ffb91cx43527c779b0bf553@mail.gmail.com>
	 <C3B522CC.BC1E%kmenard@servprise.com>

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 ...

/dev/mrg


On Jan 17, 2008 3:20 PM, Kevin Menard <kmenard@servprise.com> wrote:
> On 1/17/08 9:47 AM, "Michael Gentry" <blacknext@gmail.com> 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
>
>