I’m making a program that will post data to a database, and I’ve run into a pattern that I’m sure is familiar: A short table of most-likely (very strongly likely) fixed values that serve as an enum. So suppose the following table called Status:
Status Id Description -------------- 0 Unprocessed 1 Pending 2 Processed 3 Error
In my program I need to determine a status Id for another table, or possibly update a record with a new status Id.
I could hardcode the status Id’s in an enum and hope no one ever changes the database. Or I could pre-fetch the values based on the description (thus hardcoding that instead).
What would be the correct approach to keep these two, enum and table, synced?
5
I would hard-code the enum within your program, as I suspect these different statuses affect your programs logic. If you have a new status, how is your program supposed to react to this new status?
Because the database is part of your application, I don’t think it would make sense to affect one without consulting other, sort of speak.
4
I would normally load this data into a static cache (usually in a HashMap or something like that) when the application starts up. It avoids having to recompile just because the enum has been modified in some way.
Because those are statuses they should be hard-coded into the application to ensure no DB change will corrupt your program (at least not easily). This is important because every status that must be added has to be coded against first and not simply added to the DB.
You should still have those status values written to the DB with their correct descriptions in case you need to pull a report for example.
Usually I have a small code snippet that will connect to the DB and verify that the statuses listed in a specific table all have the same id/name values that I have hard-coded in memory. If they don’t match I will abort the execution of the software.
Depending on your needs you might want to implement slightly different behaviors but overall it’s a good idea to have those statuses hard-coded anyway.
We have similar issues on my project (legacy code, hooray!) The major problem is that “the enum tables never change” until they do and code breaks. I have two strategies to mitigate that I’ve been slowly migrating towards.
First, and best, is to eliminate direct references to these values whenever possible. Always ask, “why do I need to directly use the enum value?” In many cases, this is a sign that the code has too many hard coded assumptions or is trying to do too much manipulation on the data. See if you can’t make better relationships in the database or more flexible code to handle what is being manipulated.
When that doesn’t work, I go to plan B: code generation. Since the tables change infrequently and we publish new builds regularly, a code generator can read the enum tables and write the enum code. This dynamically generated library is then used in the project. If the DB changes, the next build will not compile, which is a lot better than getting mysterious runtime errors.
2