On Friday, August 19, 2011, Paul Davis <[email protected]> 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.
