From user-return-18229-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Sat Oct 8 02:03:13 2011 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 469C5922B for ; Sat, 8 Oct 2011 02:03:13 +0000 (UTC) Received: (qmail 84344 invoked by uid 500); 8 Oct 2011 02:03:11 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 84308 invoked by uid 500); 8 Oct 2011 02:03:11 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 84300 invoked by uid 99); 8 Oct 2011 02:03:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 08 Oct 2011 02:03:11 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.213.180] (HELO mail-yx0-f180.google.com) (209.85.213.180) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 08 Oct 2011 02:03:05 +0000 Received: by yxm34 with SMTP id 34so6137540yxm.11 for ; Fri, 07 Oct 2011 19:02:44 -0700 (PDT) Received: by 10.150.47.26 with SMTP id u26mr129235ybu.14.1318039364111; Fri, 07 Oct 2011 19:02:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.143.19 with HTTP; Fri, 7 Oct 2011 19:02:24 -0700 (PDT) From: Jamie Talbot Date: Sat, 8 Oct 2011 12:02:24 +1000 Message-ID: Subject: Differing responses for retrieving a deleted document through GET and POST To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Hi, I was wondering about what I think is an inconsistency in how searching works for documents that have been deleted. Having deleted a document, it no longer appears in _all_docs, as expected. A GET to the document URL return 404 as expected. However, POSTing the _id in 'keys' to _all_docs still returns a document with 200, albeit with deleted: true. Sample steps to reproduce are below: majelbstoat@Neptune~ $ curl -X POST http://localhost:5984/dummy/ -H "Content-Type: application/json" -d "{\"_id\": \"1234\", \"name\": \"monkey\"}" {"ok":true,"id":"1234","rev":"1-4f1a0c4ebfe937f06161d7c3d90f5cff"} majelbstoat@Neptune~ $ curl -X POST http://localhost:5984/dummy/ -H "Content-Type: application/json" -d "{\"_id\": \"5678\", \"name\": \"magic\"}" {"ok":true,"id":"5678","rev":"1-c924380de3517764a68af46a07b5fe6f"} majelbstoat@Neptune~ $ curl -X DELETE http://localhost:5984/dummy/1234?rev=1-4f1a0c4ebfe937f06161d7c3d90f5cff {"ok":true,"id":"1234","rev":"2-2e793b782be7d156372200c5878910dc"} majelbstoat@Neptune~ $ curl -X GET http://localhost:5984/dummy/_all_docs {"total_rows":1,"offset":0,"rows":[ {"id":"5678","key":"5678","value":{"rev":"1-c924380de3517764a68af46a07b5fe6f"}} ]} majelbstoat@Neptune~ $ curl -X POST http://localhost:5984/dummy/_all_docs -H "Content-Type: application/json" -d "{\"keys\": [\"1234\"]}" {"total_rows":1,"offset":0,"rows":[ {"id":"1234","key":"1234","value":{"rev":"2-2e793b782be7d156372200c5878910dc","deleted":true}} ]} majelbstoat@Neptune~ $ curl -X GET http://localhost:5984/dummy/1234 {"error":"not_found","reason":"deleted"} Is this a deliberate design decision, and if so is there a particular reason for this? I've been relying heavily on the use of HTTP status codes, and receiving 404 in one context and 200 in another is what confuses me. I can of course rewrite the logic to check for a 'deleted' key, but decoding the data to do so is less elegant and more intensive than just observing the response status. Unfortunately at the moment I have consider all 200 responses suspect, which rather diminishes its usefulness for me. (Version 1.1.0, OSX through Macports). Cheers, Jamie. --- http://jamietalbot.com