couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <B.Cand...@pobox.com>
Subject Re: struggling with couchdb in production
Date Thu, 28 May 2009 14:19:01 GMT
> 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.

Regards,

Brian.

Mime
View raw message