cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <...@ish.com.au>
Subject Re: Enum best practices
Date Wed, 16 Jan 2008 20:49:25 GMT

On 17/01/2008, at 2:43 AM, Kevin Menard wrote:

> The best way I've come up with is if the enum maps its values to the  
> PKs of
> the entries in "eval_status" table.  I think this would achieve what  
> I'd
> like, with the downside that referential integrity may be  
> compromised if I
> update one but not the other.
>
> Is this largely what others are doing?  Or, do you just use VARCHAR  
> columns
> and not worry about the normalization of the DB?

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.

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.


Have I missed the point of what you were asking?

Ari


-------------------------->
ish
http://www.ish.com.au
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



Mime
View raw message