couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (COUCHDB-825) _changes "compaction"
Date Wed, 14 Jul 2010 14:11:49 GMT

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


Mime
View raw message