incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Shumaker <>
Subject Re: how to do http request within server-side _show or _view functions?
Date Wed, 20 May 2009 19:19:09 GMT
Apparently at the cost of limiting the functionality of dozens of
unrelated features - everything from transactions to validation.

I grow ever more convinced that CouchDB's replication is an albatross.
 It's analogous to RAID-1 - easy to code but pretty limited (and now
very outdated) tech.  It wouldn't be a problem if it were an isolated
feature, but it hamstrings so many others.

Maybe it makes sense for a particular kind of project, but for most
real-world applications you can get better (more scalable, higher
performant, and more reliable) results with some sort of Paxos or
Vector-clock architecture with multiple committers and readers.  I do
hope to see CouchDB move in that direction - and I think it has a good
chance of becoming the web persistent storage engine of choice if it


On Sun, May 17, 2009 at 1:43 AM, Jan Lehnardt <> wrote:
> On 17 May 2009, at 01:28, Scott Shumaker wrote:
>> Why are the validation functions run at replication time?
> As far as the data store in CouchDB is concerned, replication is
> just another client doing GETs & PPSTs). Replication uses the
> same API any user faces.
> Cheers
> Jan
> --
>> On Tue, May 12, 2009 at 5:33 AM, Chris Anderson <> wrote:
>>> On Tue, May 12, 2009 at 1:13 AM, Scott Shumaker <>
>>> wrote:
>>>> Not ideal, but it works.  I'd love for validate_doc_update to take
>>>> HTTP headers - especially an additional JSON parameter, like a custom
>>>> userCtx.
>>> The problem with this approach is that the validation functions are
>>> run at replication time as well as at initial update time. This is why
>>> we need to abstract the http information into a userCtx, because the
>>> full request object won't be available for replay later (and the
>>> replicating userCtx is used at rep time, not the original Ctx, so
>>> replay wouldn't be appropriate anyway.)
>>> Both concerns in this thread (custom http auth & using user creds from
>>> a db) are best addressed by writing another authentication handler or
>>> two. I believe there is work underway to do this but I'm not sure the
>>> current state.
>>> We are very open to patches in the auth handler section of the code.
>>> Please inquire on dev@ (or drop a patch on
>>> if you'd like to help
>>> here.
>>> Chris
>>> --
>>> Chris Anderson

View raw message