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 does. Scott On Sun, May 17, 2009 at 1:43 AM, Jan Lehnardt <[email protected]> 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 <[email protected]> wrote: >>> >>> On Tue, May 12, 2009 at 1:13 AM, Scott Shumaker <[email protected]> >>> 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 >>> https://issues.apache.org/jira/browse/COUCHDB) if you'd like to help >>> here. >>> >>> Chris >>> >>> >>> >>> -- >>> Chris Anderson >>> http://jchrisa.net >>> http://couch.io >>> >> > >
