Looking at _changes?include_docs=true, 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=true&since=341298' {"results":[ {"seq":341299,"id":"doc1","changes":[{"rev":"2-067ab79f86426777f902f65c74597697"}],"deleted":true,"doc":{"_id":"doc1","_rev":"2-067ab79f86426777f902f65c74597697","_deleted":true}} ], "last_seq":341299} This is not coherent with _all_docs?include_docs=true. Views are not affected. Should we change _changes to send "doc: null" as well? On Mon, Feb 14, 2011 at 8:01 PM, Filipe David Manana <[email protected]> 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 > <[email protected]> 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 <[email protected]> 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=<rev> >>> curl -XPOST -d'{"keys":["foo"]}' -H'Content-Type: application/json' >>> http://localhost:5984/test_20110214/_all_docs?include_docs=true >>> >>> and you'll obviously need to replace <rev> 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-21a02b631e42e652c8ef52da9b156997","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-21a02b631e42e652c8ef52da9b156997","deleted":true},"doc":{"_id":"foo","_rev":"2-21a02b631e42e652c8ef52da9b156997","_deleted":true}} >>> ]} >>> >>> Note that instead of 'null', 1.1.x actually returns a stub document with >>> _deleted set to 'true'. >>> >>> I'm not sure if this is change in behavior is expected or not, but I didn'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 all? I >>> noticed that "total_rows" is 0 in both cases, yet there is 1 row returned. >>> >>> Thanks for your time and any insight you can provide. >>> >> >> >> >> -- >> Filipe David Manana, >> [email protected], [email protected] >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." >> > > > > -- > Filipe David Manana, > [email protected], [email protected] > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > -- Filipe David Manana, [email protected], [email protected] "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
