cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Menard <kmen...@servprise.com>
Subject Re: Enum best practices
Date Wed, 16 Jan 2008 22:32:12 GMT
On 1/16/08 3:49 PM, "Aristedes Maniatis" <ari@ish.com.au> wrote:
 
> I don't quite understand what advantage you get from the above
> approach rather than just creating a table called
> OrderEvaluationStatus and using regular relations?
> 
> For my part, I make a separation between attributes which a user might
> (even theoretically) modify and those which are tied into the
> functioning of the code. If a user might change the data (eg. states,
> postcodes, etc) then it belongs in a separate table. If tied
> instrisically to the code (eg. Invoice.status) then I'd create static
> constants in the Invoice table which point to Integer values for
> database storage. A user shouldn't then be able to create a new
> invoice status even if they have direct access to the database since
> their meaning is heavily tied up in how the code works.
> INVOICE_STATUS_CANCELLED, INVOICE_STATUS_PENDING, INVOICE_STATUS_HOLD
> or whatever.

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.

> 
> The main trouble with my approach is that there is nothing stopping a
> programming error like
> 
> invoice.setStatus(PURCHASE_STATUS_HOLD)
> 
> other than the naming convention. Enums should certainly help here.

Correct.  I think they enhance clarity in most cases as well.

> 
> Have I missed the point of what you were asking?
> 

I'm not sure.  I may not have been clear enough to start.  Do my above
comments help elucidate any?

-- 
Kevin


Mime
View raw message