Question

My application configuration is very hierarchical and fits nicely into a single XML. Soon (YAGNI, Yeh) parts of this information will be consumed by other applications remotely, which calls for a database.

So, I went into designing DB tables and mapping them back to my application’s class hierarchy (using EF). however it became a maintenance nightmare.

I’d love to hear from others experience considering this issue, thanks.

Answer 1

We had very good experience with storing the config in a database for long running applications (like web sites and services). Advantages:

• You can edit the config remotely and securely (user/password)
• It is simple for the application to pick up changes (select max(lmod) from config) automatically or by a signal (ping a web page or create an empty file somewhere)
• The application only needs a single item of configuration per environment (dev, test, prod): The DB to use. If you have an application server, your applications are config free for all environments.

The main problem is the editing if you have a complex, hierarchical config structure with defaults, lists and inheritance. Our solutions:

• The config table has these rows: Application varchar(32), Key varchar(512), Value varchar(4096)
• One DB per environment (local developer machine, development test, integration test, production)
• The key is hierarchical (option.suboption….name)
• Defaults use ‘option..name’ (for example, ‘jdbc..driver’ since we use only one type of database)
• Lists are stored as strings, separated by newline.
• Maps are stores as strings, ‘name=value\n’
• There is an implementation which can read the config from a file (for unit tests). Map each hierarchy of the key to an element (……)

Config objects hide these details, so the application just works with objects.

A special class is responsible for re-reading the config in case of a change. Usually, we update the config some time during the day and a timed job will reload it after hours. This way, we never need to synchronize the config methods.

Backup and change history were a problem, though. We fixed that by using XML files in the VCS which are then ‘uploaded’ to the DB. This way, we could verify the production config before uploading it (by using it with a special set of unit tests on a developer machine). When it got activated during the night, it usually worked right away and the operator responsible for the app would just have to do a little bit of testing.