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 > >
