Persisting data suited for enums

Question

Most projects have some sort of data that are essentially static between releases and well-suited for use as an enum, like statuses, transaction types, error codes, etc. For example's sake, I'll just use a common status enum:

public enum Status {     ACTIVE(10, "Active");     EXPIRED(11, "Expired");     /* other statuses... */      /* constructors, getters, etc. */ } 

I'd like to know what others do in terms of persistence regarding data like these. I see a few options, each of which have some obvious advantages and disadvantages:

• Persist the possible statuses in a status table and keep all of the possible status domain objects cached for use throughout the application
• Only use an enum and don't persist the list of available statuses, creating a data consistency holy war between me and my DBA
• Persist the statuses and maintain an enum in the code, but don't tie them together, creating duplicated data

My preference is the second option, although my DBA claims that our end users might want to access the raw data to generate reports, and not persisting the statuses would lead to an incomplete data model (counter-argument: this could be solved with documentation).

Is there a convention that most people use here? What are peoples' experiences with each and are there other alternatives?

Edit:

After thinking about it for a while, my real persistence struggle comes with handling the id values that are tied to the statuses in the database. These values would be inserted as default data when installing the application. At this point they'd have ids that are usable as foreign keys in other tables. I feel like my code needs to know about these ids so that I can easily retrieve the status objects and assign them to other objects. What do I do about this? I could add another field, like "code", to look stuff up by, or just look up statuses by name, which is icky.

Answer 1

We store enum values using some explicit string or character value in the database. Then to go from database value back to enum we write a static method on the enum class to iterate and find the right one.

If you expect a lot of enum values, you could create a static mapping HashMap<String,MyEnum> to translate quickly.

Don't store the actual enum name (i.e. "ACTIVE" in your example) because that's easily refactored by developers.

Answer 2

I'm using a blend of the three approaches you have documented...

Use the database as the authoritative source for the Enum values. Store the values in a 'code' table of some sort. Each time you build, generate a class file for the Enum to be included in your project.

This way, if the enum changes value in the database, your code will be properly invalidated and you will receive appropriate compile errors from your Continuous Integration server. You have a strongly typed binding to your enumerated values in the database, and you don't have to worry about manually syncing the values between code and the data.