On Jul 6, 2009, at 3:58 PM, Chris Anderson wrote:
== Deleted and Conflicts==
_all_docs_by_seq includes a 'deleted' flag and a list of 'conflicts'.
Should the _changes API to do the same?
The plan is to drive replication from changes, so anything needed by
replication is on the roadmap. I don't think it'd hurt to have any of
those but Damien would be better to answer this one.
The deleted=true flag probably won't be needed by the replicator,
because the _changes feed includes the deletion revid. I expect that
the replicator will just download this revision like any other, find
the _deleted:true bit set in the document, and delete the document on
the target.
_conflicts and _deleted_conflicts are more interesting. When one of
these occurs, the document shows up in the _changes feed, but the
revision in that row is the latest revision of the document, not the
conflict/deleted_conflict rev. Unlike _all_docs_by_seq, it's not
possible for the replicator to determine the list of revisions to
replicate solely by analyzing the _changes feed.
I think the most efficient solution is to start including conflict and
deleted_conflict revisions in the revlist in the _changes row. I don't
know the revision tree well enough to know if it's possible to
identify the set of all conflict revisions that were saved after
update_sequence N, but if it is that would be a neat restriction.
Another option might be to configure a metadata-only request so that
the replicator could check what revisions exist on the source for each
updated document. Could be a useful thing to have in general.
Best, Adam
