couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: _changes resource
Date Tue, 07 Jul 2009 03:36:07 GMT
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

View raw message