From dev-return-14915-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Mon Feb 14 21:23:58 2011 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 11858 invoked from network); 14 Feb 2011 21:23:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 14 Feb 2011 21:23:58 -0000 Received: (qmail 1269 invoked by uid 500); 14 Feb 2011 21:23:57 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 1205 invoked by uid 500); 14 Feb 2011 21:23:57 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 1197 invoked by uid 99); 14 Feb 2011 21:23:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Feb 2011 21:23:56 +0000 X-ASF-Spam-Status: No, hits=1.8 required=5.0 tests=FREEMAIL_FROM,FREEMAIL_REPLY,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com designates 74.125.83.52 as permitted sender) Received: from [74.125.83.52] (HELO mail-gw0-f52.google.com) (74.125.83.52) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Feb 2011 21:23:51 +0000 Received: by gwb11 with SMTP id 11so2393658gwb.11 for ; Mon, 14 Feb 2011 13:23:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=DMQa9I8rD24Tq6ATi8S0n2IWzhq5BdZjgagaWdUrkGk=; b=HqyXW6wU9q+mExqWHBi9iaVERh+HjZ+StU7n3cNlG7j71sdm4YuSWQFj4DEZj6KMVf Ka/FrZQqbB+tAjT2k/js7DPh72fUSfxA9ul46HHKYfc/OlQDbgMJ5QaFVZvuPsTVYQUr izz6YOKbtR1AmdK24mv3Y5ELZZL2v+30SelxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=LRVYdCnFvTJwG7v9rApEhmBrkj7mmmbCFy6kg3B/jM1x62kX35St8LcvKiBx7x3cx9 HMSRTvMetwaE6vkg5b8c7y9zm8j4Jm6gwcDa6wWUoK7S99r18aZ0PWE5MO3REGC3Ug2f 3WDd72SnuKRJACtLWLU7C9AC2YAvOLFNgBqdQ= Received: by 10.150.200.20 with SMTP id x20mr5021247ybf.56.1297718610630; Mon, 14 Feb 2011 13:23:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.147.40.17 with HTTP; Mon, 14 Feb 2011 13:22:50 -0800 (PST) In-Reply-To: References: <20110214190825.GK2154@3oh1.uhds.oregonstate.edu> From: Paul Davis Date: Mon, 14 Feb 2011 16:22:50 -0500 Message-ID: Subject: Re: inconsistent behavior in _all_docs with deleted documents To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What's the inconsistency? _all_docs shouldn't respond with *anything* if the doc is deleted as _all_docs is a representation of what's in the database when the request started. On the other hand _changes *should* show the doc (once, for the update_seq where it was deleted). None of that answers the question on whether there should be a doc there or not though. I'd lean towards including it though because we use that pattern in other places don't we? On Mon, Feb 14, 2011 at 3:47 PM, Filipe David Manana wrote: > Looking at _changes?include_docs=3Dtrue, it seems that, even before > COUCHDB-1061, it adds the deleted version of a document to the 'doc' > attribute of each line: > > $ curl 'http://fdmanana.couchone.com/large1kb_copy/_changes?include_docs= =3Dtrue&since=3D341298' > {"results":[ > {"seq":341299,"id":"doc1","changes":[{"rev":"2-067ab79f86426777f902f65c74= 597697"}],"deleted":true,"doc":{"_id":"doc1","_rev":"2-067ab79f86426777f902= f65c74597697","_deleted":true}} > ], > "last_seq":341299} > > This is not coherent with _all_docs?include_docs=3Dtrue. Views are not af= fected. > > Should we change _changes to send "doc: null" as well? > > On Mon, Feb 14, 2011 at 8:01 PM, Filipe David Manana > wrote: >> It's now corrected in the latest revision. >> I added a test to help prevent this from happening again. >> >> cheers >> >> On Mon, Feb 14, 2011 at 7:13 PM, Filipe David Manana >> wrote: >>> That's probably a side effect from a recent change I made: >>> https://issues.apache.org/jira/browse/COUCHDB-1061 >>> >>> I'll check it later and correct it if it's related. >>> >>> cheers >>> >>> On Mon, Feb 14, 2011 at 7:08 PM, Gordon wrote: >>>> Hello, >>>> >>>> I noticed a change in behavior from 1.0.1 to 1.1.x regarding _all_docs= and >>>> deleted documents. >>>> >>>> I've got a series of cURL commands that reproduce the "issue" for me. >>>> >>>> curl -XPUT http://localhost:5984/test_20110214 >>>> curl -XPUT -d '{"_id":"foo","data":"bar"}' -H'Content-Type: >>>> application/json' http://localhost:5984/test_20110214/foo >>>> curl -XDELETE http://localhost:5984/test_20110214/foo?rev=3D >>>> curl -XPOST -d'{"keys":["foo"]}' -H'Content-Type: application/json' >>>> http://localhost:5984/test_20110214/_all_docs?include_docs=3Dtrue >>>> >>>> and you'll obviously need to replace with the revision returned = by the >>>> previous command. >>>> >>>> On 1.0.1, this results in something like the following: >>>> >>>> {"total_rows":0,"offset":0,"rows":[ >>>> {"id":"foo","key":"foo","value":{"rev":"2-21a02b631e42e652c8ef52da9b15= 6997","deleted":true},"doc":null} >>>> ]} >>>> >>>> However, on 1.1.x, this results in something like the following: >>>> >>>> {"total_rows":0,"offset":0,"rows":[ >>>> {"id":"foo","key":"foo","value":{"rev":"2-21a02b631e42e652c8ef52da9b15= 6997","deleted":true},"doc":{"_id":"foo","_rev":"2-21a02b631e42e652c8ef52da= 9b156997","_deleted":true}} >>>> ]} >>>> >>>> Note that instead of 'null', 1.1.x actually returns a stub document wi= th >>>> _deleted set to 'true'. >>>> >>>> I'm not sure if this is change in behavior is expected or not, but I d= idn't >>>> want to file a bug report without checking with the list first. >>>> >>>> The second question this led me to: do we want to return any rows at a= ll? I >>>> noticed that "total_rows" is 0 in both cases, yet there is 1 row retur= ned. >>>> >>>> Thanks for your time and any insight you can provide. >>>> >>> >>> >>> >>> -- >>> Filipe David Manana, >>> fdmanana@gmail.com, fdmanana@apache.org >>> >>> "Reasonable men adapt themselves to the world. >>> =A0Unreasonable men adapt the world to themselves. >>> =A0That's why all progress depends on unreasonable men." >>> >> >> >> >> -- >> Filipe David Manana, >> fdmanana@gmail.com, fdmanana@apache.org >> >> "Reasonable men adapt themselves to the world. >> =A0Unreasonable men adapt the world to themselves. >> =A0That's why all progress depends on unreasonable men." >> > > > > -- > Filipe David Manana, > fdmanana@gmail.com, fdmanana@apache.org > > "Reasonable men adapt themselves to the world. > =A0Unreasonable men adapt the world to themselves. > =A0That's why all progress depends on unreasonable men." >