Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 712E01046A for ; Mon, 12 Aug 2013 23:19:54 +0000 (UTC) Received: (qmail 13016 invoked by uid 500); 12 Aug 2013 23:19:53 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 12968 invoked by uid 500); 12 Aug 2013 23:19:53 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 12886 invoked by uid 99); 12 Aug 2013 23:19:53 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Aug 2013 23:19:53 +0000 Date: Mon, 12 Aug 2013 23:19:53 +0000 (UTC) From: "Filippo Fadda (JIRA)" To: dev@couchdb.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (COUCHDB-1868) Using multiple keys, the _all_docs built-in view acts differently then a user defined view MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/COUCHDB-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13737509#comment-13737509 ] Filippo Fadda commented on COUCHDB-1868: ---------------------------------------- OK, I think I got the snippets I should modify. Tell me if I'm wrong. I tell you what I understood. First of all, internally, for each request, the lookup function is called. This function check the btree for the given key: https://github.com/apache/couchdb/blob/cc35be3b6fa0bc1eefe4954793131ef3541b47da/src/couchdb/couch_btree.erl#L214 This function return 'ok' in case of match or 'not_found'. Speaking of _all_docs, I found that the 'all_docs_fold' function checks if the pattern 'not_found' is matched. In this case a row with the error is emitted, but this doesn't happen, instead, in the 'view_cb' function, used internally when you query a user defined view. The function in fact ignores the 'not_found' pattern matching and only deals with 'ok'. That's because it just returns rows for existing keys. So, I have to add the option and modify the above functions (all_docs_fold, view_cd) to emit a row with a null id in case of the new query parameter is true, ignoring the pattern matching 'not_found' in case the _all_docs or the user defined view are called without the new query parameter. > Using multiple keys, the _all_docs built-in view acts differently then a user defined view > ------------------------------------------------------------------------------------------ > > Key: COUCHDB-1868 > URL: https://issues.apache.org/jira/browse/COUCHDB-1868 > Project: CouchDB > Issue Type: Bug > Components: View Server Support > Reporter: Filippo Fadda > > When you query a view using multiple keys, the _all_docs built-in view acts differently then a user defined view: > 1) in the first case CouchDB returns "not_found" for every not found key; > 2) querying a user defined view produces, instead, an empty array. > In the first case you obtain error="not_found" for every key, when you query a user defined view you simply don't get any rows, just the total rows for the view. > See: http://pastebin.com/D7NExJrd > Now, regarding 'keys' the documentation says something like: "Used to retrieve just the view rows matching that set of keys. Rows are returned in the order of the specified keys." > In a normal case, CouchDB should return just a row for each matched key, but it will really help, having an option to return a row for every key, even there if not found, because it's more easy, cycle through results. > Let's suppose the application I'm doing gets the last 30 blog posts, displaying for each one, information that are stored into related documents. The application will query, using as keys the posts' identifiers, other views to get, for example, if a post has been starred from the current logged-in user, etc. > If a view always returns a number of rows equals to the number of keys, the application can cycle from 0 to 29 and display all the related information for a post. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira