views:

23

answers:

1

Hi All,

My application has a xml based configuration. It has also a xsd file. Before my application starts, xmllint will check the configuration against the xsd file.

With the growth of my application, the configuration structure has changed a bit. Now I have to face this problem: When I provide a new version of my application to customer, I have to upgrade the existing configuration.

How to make this done easy and clever?

My idea is to build a configuration object using python, and then read configuration v1 from file and save it as v2. But if later the structure is changed again, I have to build another configuration object model.

+1  A: 

For all configuration settings that remain the same between configurations, have your installation script copy those over from the old config file if it exists. For the rest, just have some defaults that the user can change if necessary, as usual for a config file. Unless I've misunderstood the question, it sounds like you're making a bigger deal out of this than it needs to be.

By the way, you'd really only need one "updater" script, because you could parametrize the XML tagging such that it go through your new config file/config layout file, and then just check the tags in the old file against that and copy the data from the ones that are present in the new file. I haven't worked with XSD files before, so I don't know the specifics of working with them, but I don't think it should be that difficult.

JAB
For instance: the old configuration looks like<config> <foo> <item1 attr1=".."/> </foo></config>But in the new configuration, it looks:<config> <bar> <item1 attr1=".."/> </bar></config>The value inside foo might be customer relevant. By upgrading I have to rename the section foo to bar.
stanleyxu2005
@stanley: If your changes are that big, then you probably will have to do separate upgrade scripts for each version change. However, if the upgrades don't happen that often, it may not be that bad. You'll definitely want to make sure that you can chain the file changes, though, because there's always a possibility of a user using a version of the program older than the last version, such that the changes required are now even greater.
JAB
Really, though, if you want to keep the upgrade process as simple as possible, keep the layout of the config file as close to the original as you can. If, for whatever reason, that isn't possible (due to a complete change in the way your program works and stores its configuration), you could possibly reduce the effort required on your part by having the customer re-enter some stuff when they upgrade, but I wouldn't really recommend that, all things considered.
JAB