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