couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: struggling with couchdb in production
Date Thu, 28 May 2009 14:33:08 GMT

On May 28, 2009, at 10:19 AM, Brian Candler wrote:

>> You can use [open_]revs=all to open all the conflicts (deleted  
>> conflicts
>> too)
> Ah, open_revs=all is new to me - it works fine, although knowing about
> deleted revisions isn't of particular interest. What I want is all  
> live
> (current) conflicting versions.
> It seems to me that this is something that Amazon Dynamo got right:
> * A GET gives you all "live" versions of a document, plus an opaque
>  context
> * A PUT of an updated document (which includes this context object)
>  replaces the corresponding set of old versions with this one
> * A PUT never fails, but may introduce conflicting versions
> This is both simple and powerful, and dealing with conflicts would  
> then
> become pretty pretty easy. As a side benefit: you would no longer  
> need an
> API to fetch an item by _rev, which would make it less likely that  
> people
> would confuse CouchDB with an RCS :-)
> There is only one reason I can see that CouchDB picks a "preferred"  
> version
> from amongst the conflicts, and that is for the benefit of views.  
> However,
> even that problem goes away if you just pass *all* versions of a  
> document to
> the map function.
>  function(docs) { ... }
> The map function may then choose to:
> - emit keys corresponding to docs[0] only (= current behaviour)
> - emit keys corresponding to all docs
> - perform some application-specific view merging
> As long as the conflicting versions of the doc are returned in a
> deterministic order, then both clients and views *could* choose to  
> work in
> the current way (by just picking the first version and ignoring the  
> others),
> but they would be encouraged to highlight and/or resolve the  
> conflicts at
> the earliest opportunity.
>> Also, bulk document retrieval via POST where the post body specifies
>> the docs and revisions is something we'd like to see added to the
>> front end too.
> I think this is adding more complexity to the API. When would you  
> really
> want to get a specific rev or set of revs, rather than *all* live
> conflicting revs?
>> Patches welcome, I and others in community will be glad to help you.
> I suspect that what I'm suggesting is too radical to stand much  
> chance of
> being merged :-( The path of least resistance, for now, is to avoid  
> all
> replication other than master->slave.

Doesn't sound too radical at all. I'd like to see how well it works in  


View raw message