From user-return-4631-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Wed Apr 29 05:32:21 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 95652 invoked from network); 29 Apr 2009 05:32:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 29 Apr 2009 05:32:21 -0000 Received: (qmail 82823 invoked by uid 500); 29 Apr 2009 05:32:20 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 82727 invoked by uid 500); 29 Apr 2009 05:32:19 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 82715 invoked by uid 99); 29 Apr 2009 05:32:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Apr 2009 05:32:19 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.146.180 as permitted sender) Received: from [209.85.146.180] (HELO wa-out-1112.google.com) (209.85.146.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 29 Apr 2009 05:32:11 +0000 Received: by wa-out-1112.google.com with SMTP id m38so431117waf.27 for ; Tue, 28 Apr 2009 22:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=NVkk2V7LVbc2V0iz61Er2gP9WafOZD2+MbObCcidZOY=; b=kriTvRWUSkmvHZa5vzhTe99sslML8lRAEGxpMNQt47Dw3XYwauW79TeL5a7OOxS+vt M/lnO/F51kEZfiRyr3H+tCkVdQ9smCiQJZ9RPjKsbvoiR/i/htPuA+hsKZ4Z8J6PYJ6O O+Iz9YONQjWVFKr6WHWpHK90Ef/lCBvDMQ6C4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=rNkjnS4wC0T6iLoBTj+tKAFLjDNhkPGzECceEfCYDVgi9FGGcnkBE9bGsOOjvBSkWU Soo6wKFrdWTjYpmlArMPMBiJVK2w05EbBiiW6blJYJjh5wzTUMIqRCA2Z/sQO7BbnMIQ GJC0Xg0Q5XVtfEfSBbWSday677BPvr1b8GCqs= Received: by 10.114.181.6 with SMTP id d6mr3668378waf.8.1240983111465; Tue, 28 Apr 2009 22:31:51 -0700 (PDT) Received: from ?10.71.0.44? (216.112.110.172.ptr.us.xo.net [216.112.110.172]) by mx.google.com with ESMTPS id q18sm2598488pog.19.2009.04.28.22.31.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Apr 2009 22:31:50 -0700 (PDT) Message-ID: <49F7E635.90407@gmail.com> Date: Tue, 28 Apr 2009 22:31:33 -0700 From: Paul Davis User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: user@couchdb.apache.org Subject: Re: Howto drop rows with reduce? References: <49F5DE56.8000600@gmail.com> <20090428120744.GA10994@uk.tiscali.com> <49F73464.6040209@gmail.com> <20090428192836.GA17244@uk.tiscali.com> <49F77275.5020708@gmail.com> <2113AE88-85F5-4256-8BEE-E26E6D90B31A@truthtrap.com> In-Reply-To: <2113AE88-85F5-4256-8BEE-E26E6D90B31A@truthtrap.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Jurg van Vliet wrote: > hi people, > > (this is my first 'sound' on this list, so hi again. i am enjoying > couchdb, especially when seeing how many people are having fun doing > 'something different'. so, thank you for showing me what you are doing.) > > for our project we am using couchdb as the general datastore. we store > everything in a document in couchdb, and we distiguish type explicitly > (with a field in the document.) suppose we have articles and files and > comments. > > both articles and files have (nested) comments. a comment stores its > path, and this way models its ancestry. there is no reference from > either article or file to comments, as this is not necessary. > > (getting this to work with couchdb already forced us to learn (and > accept) couchdb for what it is :) difficult, but fun!) > > now, suppose we want to list articles ordered by the number of > comments. at first glance this is easy, and the solution is similar to > the tag solutions you find by googling. but we want a view that gives > us only the articles, we don't want the files. (we want separate views > for files, and other types of documents containing comments.) > > the solution we thought of was 'a bit of a hack', but it should work. > the map code for the document type article looks like this > > function(doc) { > if( doc.type == 'Article') { > emit( doc._id, 0); > } else if( doc.type == 'Comment') { > emit( doc.path[0], 1); > } else { > emit( doc._id, "a"); > } > } > Is there a reason you have this last emit statement? There's nothing forcing you to emit anything. So you could just delete the last if clause and then those docs won't be in your reduce. In the only way to drop a reduce row is to not emit it. Paul Davis > here you see that we emit everything, but we emit a non-number value > when the type is not what we want. a simple reduce would drop the rows > that have values that are not-a-number leaving us with exactly what we > want. the reduce could look like this: > > function( keys,values,rereduce) { > var total = sum( values); > > if( !isNaN( total)) { > return total; > } > } > > but this gives an error about a 'bad_cause', at least in futon. adding > something like 'return null' doesn't help very much, because it > doesn't exclude what we don't want to see. > > my questions are > 1. how can we exclude things from the result of the view with reduce, > in other words 'how to drop rows with reduce'? > 2. how else can you attack this problem? > > thanks, > jurg. > > a little of bit of context: we are creating a rails application > following basic_model and couchrest. everyone is still struggling with > understanding couchdb, including us. so we decided to stick with this > for a while, and patch little things for what we need in our > application. we choose to design the documents as close as possible to > the rails models. as a result we implemented views on the level of a > model, because that is the way we look at our problem. we have certain > views for articles, for files, for users, etc. perhaps this direction > of implementation doesn't get us to where we want to go. so (almost) > any suggestion is welcome:) we still want to have multiple types of > information in one couchdb database, though.