couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: [jira] [Created] (COUCHDB-1252) A way to have views return _deleted documents
Date Fri, 19 Aug 2011 06:57:51 GMT
On Friday, August 19, 2011, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> I don't think its an issue that the 404 is there. It *is* deleted after
all. Though there's an argument to be made why we don't show the deleted
body in the response.
>
> I would say that it should be a view option, but this will get a bit wonky
for you. You'll need to see if *any* of the views have it included and then
read the body from disk in the enum_changes_since loop. After that you'll
have to filter it before passing it to the doc mapper. Also, I'm currently
in the middle of rewriting the entire view engine so I wouldn't go too far
if you end up needing to change lots of code.
>
> Also, you can't see them in a view because we've never had the request to
write this patch. It wasn't *too* long ago that it was impossible to see
_design docs in a view (and now that's even off by default).
>
> On Aug 18, 2011, at 11:07 PM, Jason Smith (JIRA) wrote:
>
>>
>>    [
https://issues.apache.org/jira/browse/COUCHDB-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087509#comment-13087509]
>>
>> Jason Smith commented on COUCHDB-1252:
>> --------------------------------------
>>
>> To Damien, I say: well, why can't I see deleted docs in a view? Why do I
get a 404 when I query for them? Because they are deleted. Damien's code
contradicts Damien's words, and the code makes better sense. To expose
_deleted documents everywhere is a leaky abstraction.
>>
>> However, in the spirit of "design by committee is bad" and to learn a
different part of CouchDB, I would like to write this patch. Paul, should it
be a design option or a view option?
>>
>> For example:
>>
>> { "_id": "_design/example"
>> , "options": { "these_are":"options global to the ddoc",
"local_seq":true, "include_deleted":true}
>> , "views":
>>  { "deleted_docs_A":
>>    { "options": {"these_are":"local to this view", "include_design":true,
"include_deleted":true}
>>    , "map":"function(D) { if(D._deleted) emit(D._id, 1) }"
>>    }
>>  , "deleted_docs_B":
>>    { "options": {"not using include_deleted": true}
>>    , "map":"function(D) { if(D._deleted) emit(D._id, 1) /* Does it emit?
*/ }
>>    }
>>  }
>> }
>>
>> With design options, deleted_docs_B will emit, but using view options, it
won't. I prefer it to be per-view. In fact I did not even realize design
options existed until I checked the source.
>>
>> Thoughts? Thanks.
>>
>>> A way to have views return _deleted documents
>>> ---------------------------------------------
>>>
>>>                Key: COUCHDB-1252
>>>                URL: https://issues.apache.org/jira/browse/COUCHDB-1252
>>>            Project: CouchDB
>>>         Issue Type: New Feature
>>>         Components: JavaScript View Server
>>>   Affects Versions: 1.1, 1.0.3
>>>           Reporter: James Howe
>>>
>>> Given that documents can be 'soft' deleted / deleted with auditing data
by updating the document to include the _deleted property, it would be
incredibly useful if there were a way to access these documents in a map
function. Otherwise it is very difficult to find the auditing data - even
more so if the original ids are unknown.
>>> I was thinking along the lines of a view query parameter
'include_deleted', but don't really mind how this is implemented, as long as
it is there.
>>
>> --
>> This message is automatically generated by JIRA.
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
>
>

maybe we should return a 410 instead of a 404 on  _deleted but i'm n,ot sure
it really worth it. 404 czn be a temporary response according the spec.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message