having enumerations as tables is somewhat dubious, since the class that corresponds to this enumeration has fixed type-safe constants while the table itself can be manipulated .. that way it's easy to have a situation in which the code is out of sync with the database
having enumerations as simple column values is interesting in that Hibernate can easily work with that (by means of a UserType), and I'm not 100% sure but I think it's also better performance wise, since no joins are ever needed . I guess this depends on the database you're running anyway, the database can still be updated to reflect changes in the enumeration class but it will mean a search&replace (which is not too costly anyway) in your case I can see why having a table/enumeration is interesting, the best way to proceed for you is probabaly editing the enumeration template yourself, or at least create a new one .. for example associated with classes that have both <<Entity>> and <<Enumeration>> -- Wouter Zoons - [EMAIL PROTECTED] http://www.andromda.org/ _________________________________________________________ Reply to the post : http://galaxy.andromda.org/forum/viewtopic.php?p=3301#3301 Posting to http://forum.andromda.org/ is preferred over posting to the mailing list! ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Andromda-user mailing list Andromda-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/andromda-user
