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
practice.
-Damien
