couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Joseph Davis (Commented) (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1446) Config settings input validation
Date Tue, 20 Mar 2012 05:04:02 GMT


Paul Joseph Davis commented on COUCHDB-1446:

I've seen similar reports but nothing scary enough to worry too much. Though your comment
sparks an idea:

What if all config values are specified as Erlang terms, perhaps even so much as going to
a full on Erlang term file format and then for each setting that's available we create a function
that does input validation. Also, similarly we can store help information along with the function
that does validation and then use that in building docs (we have a similar thing in Gunicorn
that seems to work well enough).

Also, this would allow apps to register functions at boot to allow the system to be extensible.
Settings that don't have a validator are stored but not used (or rather, if they they shouldn't
cause failures, etc). Only thing I see is what to do if you register a handler for a value
that exists but is invalid. Perhaps replace it?

Anyway, good idea, just not sure on the details (ie, tuples only? what about tuples that contain
terms? Or our handful that are lists?)
> Config settings input validation
> --------------------------------
>                 Key: COUCHDB-1446
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Database Core
>    Affects Versions: 1.2
>            Reporter: Jason Smith
>            Assignee: Jason Smith
>            Priority: Minor
>              Labels: config
> Today I received a bug report from a user who thought CouchDB might be relaxing and evaluate
an arithmetic expression in the config. (That makes sense, since it seems to evaluate erlang
terms elsewhere.)
> It would be nice for CouchDB to validate config input, particularly when bad values permanently
take it offline. (In this case, it returns 500 for all subsequent requests.)
> IMO, a good bang-for-buck is to have three basic value types:
> 1. String
> 2. Erlang tuple
> 3. Integer
> And each setting knows what type it must be.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message