couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Davis" <>
Subject Re: Config Validators
Date Tue, 13 Jan 2009 23:44:02 GMT
On Tue, Jan 13, 2009 at 2:16 PM, Damien Katz <> wrote:
> I see the danger of the admin setting a value that then disables the server,
> they could do that anyway by editing the ini file. I think instead of
> validators, we should just contain a stern warning in Futon that any bad
> change to the config could cause the server to crash and un-restartable and
> to repair it they will need to manually edit the INI.

A stern warning doesn't catch typos, mis-behaving scripts etc. I'd
rather have an error thrown when something unexpected happens instead
of crashing a production environment. I very much disagree that we
shouldn't make some effort to inform people that a change will break
things catastrophically.

> The problem is Config validators are trying to provide training wheels to
> the users who need and desire it least, administrators. And we can't be
> expected to validated every input to see if it will work properly before it
> takes effect. Changing the config is inherently dangerous.

So basically we should just stand at the edge of the cliff and watch
administrators jump off and go splat? I don't see why you think of it
as training wheels for new users. Administrators are very capable of
making mistakes. We may not be able to check every possible config
permutation for safety, but we can catch quite a few silly errors.

> I completely agree giving nice error messages on start up when possible is a
> very good thing, but we don't need validators to do that, we just need to
> add it to the code in each module's init code to print nice error messages
> for common failures.

Config validators were intended as a way to take the error detection
code out of the init function and put it somewhere that could be run
when the config changes thus providing the entire facility for runtime
checking. To me its a simple system with a good cost/benefit ratio.

Paul Davis

> -Damien
> On Jan 13, 2009, at 1:48 PM, Ulises wrote:
>>> And I choose a slightly modified form of 2, but have the config module
>>> call each registered validator immediately and then close things down
>>> if one fails.
>> The problem is that validators are registered asynchronously so, from
>> the config's point of view, you can't be sure you've ran them all once
>> you're done loading the config. From the module's point of view,
>> however, once you start pulling values out of the config you know
>> they've been loaded. I think that checking that a value is valid in
>> the init() of a module might be a better approach.
>> Generally, though, does this whole validators thingie make sense?
>> U

View raw message