Currently, enumerations are translated to an entity with some global instances. While this is a convenient implementation, it does not provide nice behavior when making changes to the program. When a global var is changed, its properties are not updated if the application is deployed on an old database. This makes sense for such global vars, but for an enumeration it would be better if the name of the option (a global var property) is updated.
A more specialized implementation also means the enumeration options do not have to go into the database. These could be automatically generated numbers instead, or user-defined symbols to allow easier debugging and migrations of the database.

Submitted by Danny Groenewegen on 30 May 2010 at 23:51

On 31 May 2010 at 08:33 Sander Vermolen commented:

Yay.+1 from the Acoda team :)
No longer storing data model information as data in the database would ease database migration a lot. Furthermore, I can then support database migration on changes of an enumeration like: merging enumeration values, or even changing enumeration value numbering. That would make Acoda compliant to the couplings library we recently submitted to MODELS.

Log in to post comments