CouchDB
  1. CouchDB
  2. COUCHDB-1279

Deleted documents persist in View results

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.0.3
    • Fix Version/s: None
    • Component/s: Database Core
    • Labels:
      None
    • Environment:

      CouchDB 1.0.3, Centos 64 bit

    • Skill Level:
      Dont Know

      Description

      Previously deleted documents are returned as results in a View.

      View results yield

      { error: not_found, reason: deleted }

      when queried by id and are not returned in _all_docs.

      Compacting the database does not fix the issue. Deleting the View and rebuilding did not fix the issue. Deleting the view then compacting, then rebuilding the view did not fix the issue. Currently, the only way I know how to get around it is to delete/rebuild the database.

      These documents would have been deleted programmatically, so I can't be certain about the exact create/update/delete scenario the have gone through. These particular documents could have been around for a long while before I even noticed them. The biggest issue I have with this bug is that it means I can't bulk delete any documents when this bug occurs because of the update conflict it creates.

      May be related: http://stackoverflow.com/questions/7323285/couchdb-views-not-being-updated-after-delete

        Activity

        Hide
        Chris Gomez added a comment -

        Realizing that this may be a CouchBase issue, I started a thread in their support forum: http://www.couchbase.org/forums/thread/deleted-documents-persist-view-results

        Show
        Chris Gomez added a comment - Realizing that this may be a CouchBase issue, I started a thread in their support forum: http://www.couchbase.org/forums/thread/deleted-documents-persist-view-results
        Hide
        Alex Markham added a comment -

        We have noticed this on couch 1.0.3 on centos 64bit - possibly spidermonkey 1.9.2

        Where deleted docs removed by adding "_deleted":true would still show in views.
        We have multiple couches replicating in our system and this would appear irregularly, with some deleted documents showing in views on some couches and not on others without any obvious correlation.
        Removing the document attachments before adding "_deleted":true seemed to reduce the frequency of this occurring.

        I even tried deleting the view cache file (.view) and reindexing the whole view on one couch, but it still showed the issue, even showing the _deleted_conflicts field on some.
        The old views were from b 1.0.2, but when we added new views after the update to 1.0.3 (with the same functions), the problem seemed to go away.

        Show
        Alex Markham added a comment - We have noticed this on couch 1.0.3 on centos 64bit - possibly spidermonkey 1.9.2 Where deleted docs removed by adding "_deleted":true would still show in views. We have multiple couches replicating in our system and this would appear irregularly, with some deleted documents showing in views on some couches and not on others without any obvious correlation. Removing the document attachments before adding "_deleted":true seemed to reduce the frequency of this occurring. I even tried deleting the view cache file (.view) and reindexing the whole view on one couch, but it still showed the issue, even showing the _deleted_conflicts field on some. The old views were from b 1.0.2, but when we added new views after the update to 1.0.3 (with the same functions), the problem seemed to go away.
        Hide
        Jan Lehnardt added a comment -

        Hey, thanks for the report. This is definitely Couchbase 2.0 related, but currently this works according to spec (and is not a bug) of Couchbase 2.0 (think of the definition of a view as being always stale=ok in CouchDB-land), we are working towards mirroring the CouchDB API fully but we are not there yet.

        Closing this one then.

        Show
        Jan Lehnardt added a comment - Hey, thanks for the report. This is definitely Couchbase 2.0 related, but currently this works according to spec (and is not a bug) of Couchbase 2.0 (think of the definition of a view as being always stale=ok in CouchDB-land), we are working towards mirroring the CouchDB API fully but we are not there yet. Closing this one then.
        Hide
        Jan Lehnardt added a comment -

        @Alex, I didn't see your comment, sorry. Can you provide a test script that reproduces the issue?

        Show
        Jan Lehnardt added a comment - @Alex, I didn't see your comment, sorry. Can you provide a test script that reproduces the issue?
        Hide
        Matt Parker added a comment -

        i have the same problem on couchdb 1.1.0. a document was deleted on server 1. that deletion was replicated to the same database on server 2. the document was removed from the view on server 1. the document persists in the view on server 2, even though server 2 reports the document as deleted. help!

        Show
        Matt Parker added a comment - i have the same problem on couchdb 1.1.0. a document was deleted on server 1. that deletion was replicated to the same database on server 2. the document was removed from the view on server 1. the document persists in the view on server 2, even though server 2 reports the document as deleted. help!
        Hide
        Matt Freeman added a comment - - edited

        <snip>My bug report was not accurate, newb mistake, things working as they should now I've corrected my stupidity </snip>

        Show
        Matt Freeman added a comment - - edited <snip>My bug report was not accurate, newb mistake, things working as they should now I've corrected my stupidity </snip>
        Hide
        Paul Joseph Davis added a comment -

        @Matt,

        Can you get me a copy of the db file that exhibits this or shell access to a machine that I can build CouchDB on that has a copy of this file? Sounds deterministic enough but the fact that so few people have seen it means its probably quite the subtle condition.

        Show
        Paul Joseph Davis added a comment - @Matt, Can you get me a copy of the db file that exhibits this or shell access to a machine that I can build CouchDB on that has a copy of this file? Sounds deterministic enough but the fact that so few people have seen it means its probably quite the subtle condition.
        Hide
        Dave Cottlehuber added a comment -

        Please re-open if we can capture specific data.

        Show
        Dave Cottlehuber added a comment - Please re-open if we can capture specific data.

          People

          • Assignee:
            Unassigned
            Reporter:
            Chris Gomez
          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development