in reply to Re: Configuration Files
in thread Configuration Files

Perhaps I didn't explain the problem properly.. The config will be updated (just not very often), and the goal of the project is to make manual editing of config files (including Apache config) more or less non-existant. So I have an application that generates these config files, which then get read on the other side.

I could generate them in a way so that they're written as a set of variables, and read in to Apache, but there are going to be a lot (about 20+ a week are created), and there's quite a lot of data in each, so I'm concerned that the memory usage would be too great (hence my current solution).

I hope that makes it a little clearer..

Replies are listed 'Best First'.
Re^3: Configuration Files
by dragonchild (Archbishop) on Nov 02, 2004 at 16:33 UTC
    Let me paraphrase what I hear you saying:
    1. I've got a problem that says "Use a database to solve me"
    2. I don't want to use a database
    3. Any suggestions?

    Seriously, you really want to use a lightweight database solution for this. Something like MySQL, SQLite, or BerkleyDB.

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]

      There are two reasons why I'm not using a database (a database was my initial thought as well). Firstly, reliabilty is crucial. The system does write data to a database, but should that database be down, it has other (multiple) mechanisms so that no data is lost. I could possibly do something similar on the config side (ie. have a failover config file, but normally read out of the database), and that might not be a bad option, but I'm wondering if there are any others.

      The other reason is mainly political - the current application doesn't use a database for it's config (although it's woefully inefficient), but it's realiable (ie. there's no DB server to go down). Reliability is above efficiency in this project..

      The ideal would be to have some sort of High Availability Db server in place, but that infrastructure doesn't currently exist. Hopefully, I can do this in the future, but currently my hands are tied.

[reply]
        In my experience, databases (well, good databases, not toy things like MySQL) are far more reliable than file systems. Sure, your database could not be available, but so could your filesystem. And your database will not corrupt your configuration data if your application dies halfway writing the configuration file. Rest assured that anything based on doing simple write(2)s will happily leave your data in a corrupt state if the application dies halfway. Or worse, if the application dies after thinking it finished writing the data (but alas, some of it was still in a buffer somewhere).

        Using your filesystem instead of a database for reliability is like "going to war for peace" or "fucking for virginity". Larry Ellison wouldn't be as rich as he is now if filesystems were as reliable as databases.

        The ideal would be to have some sort of High Availability Db server in place, but that infrastructure doesn't currently exist. Tell, you do at least have a HA filesystem? And your application itself is running in a cluster? Otherwise, all you will be doing is window dressing.

[reply]

In Section Seekers of Perl Wisdom