couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: inconsistent behavior in _all_docs with deleted documents
Date Mon, 14 Feb 2011 21:40:56 GMT
On Mon, Feb 14, 2011 at 4:38 PM, Adam Kocoloski <kocolosk@apache.org> wrote:
> Let's write down the spec somewhere before we go changing any more maintenance branch
code.  BigCouch struggled with maintaining compatibility on this issue for a while.  There's
not really an intuitive answer here, so we just need to pick one and stick with it.
>
> Adam

+1 for not changing behavior on old branches and writing down the
arbitrary answer somewhere.

>
> On Feb 14, 2011, at 4:22 PM, Paul Davis wrote:
>
>> 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
>> <fdmanana@apache.org> wrote:
>>> 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
>>> <fdmanana@apache.org> 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
>>>> <fdmanana@apache.org> 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 <tsr2600@gmail.com> 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,
>>>>> fdmanana@gmail.com, fdmanana@apache.org
>>>>>
>>>>> "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,
>>>> fdmanana@gmail.com, fdmanana@apache.org
>>>>
>>>> "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,
>>> fdmanana@gmail.com, fdmanana@apache.org
>>>
>>> "Reasonable men adapt themselves to the world.
>>>  Unreasonable men adapt the world to themselves.
>>>  That's why all progress depends on unreasonable men."
>>>
>
>

Mime
View raw message