[
https://issues.apache.org/jira/browse/COUCHDB-825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson resolved COUCHDB-825.
------------------------------------
Resolution: Won't Fix
Harry,
The replication model (and the way _changes would work on a large cluster) mean
that it can't ever do this.
We don't replicate all intermediate states, we just replicate the current
state. Also, if compaction occurs between your delete and the time the next
line happens in _changes (imagine a slow client) there may be nothing to show.
If you tell us more about your use case maybe we can help you find the right
way to support it with CouchDB.
Chris
> _changes "compaction"
> ---------------------
>
> Key: COUCHDB-825
> URL: https://issues.apache.org/jira/browse/COUCHDB-825
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
> Affects Versions: 0.11
> Reporter: Harry Vangberg
> Attachments: test_all_changes.js
>
>
> If I create a document, delete it again and after that pulls the _changes
> feed, it only has one result, for the revision where the document it is
> deleted. I would expect it to have two results: one for the creation and one
> for the deletion. On IRC I was told it shouldn't behave like that, and it is
> kinda crucial for my use of the _changes feed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
