From user-return-5872-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Fri Aug 07 18:04:42 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 439 invoked from network); 7 Aug 2009 18:04:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 7 Aug 2009 18:04:42 -0000 Received: (qmail 38831 invoked by uid 500); 7 Aug 2009 18:04:48 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 38760 invoked by uid 500); 7 Aug 2009 18:04:48 -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 38749 invoked by uid 99); 7 Aug 2009 18:04:48 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Aug 2009 18:04:48 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates 209.85.212.177 as permitted sender) Received: from [209.85.212.177] (HELO mail-vw0-f177.google.com) (209.85.212.177) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Aug 2009 18:04:37 +0000 Received: by vws7 with SMTP id 7so1657207vws.29 for ; Fri, 07 Aug 2009 11:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=e6gK90zacmLuus3D+9zCkh20HWtdFt/b0nxR1VA5z8k=; b=c191BnAjtJh3jSVFJzTEeohNIxCPEKYVHmcn8Q+w/abKYO5KLrG59CLbeJ5XeqNhu0 mYU4sXAiKSTBrAkur3XWFSB3jV3wz1LTQjfGx37sCgsA9dgoq2j2aSZIz7kaItCPzfog 2GhAJMU0o6Nh8W17tkjKYiKoKQTMefqAOSUzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=efXeBu61+UfuwCjsfU4uqmLQf22ehIMN7bg4hD8Smvk2qAbIhcDMwLALsgx0G4TXzJ P6BIIyke0y9T6MsqGQDPTYcUR45TB2CIa+bfhnbhEKuej5/L557wcnEcVdbtYrII9bPk IjjdrrphJr9jUk4SDTd1JmPbumJ8as/kPagHg= MIME-Version: 1.0 Sender: jchris@gmail.com Received: by 10.220.46.77 with SMTP id i13mr1278305vcf.87.1249668256446; Fri, 07 Aug 2009 11:04:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Aug 2009 11:04:16 -0700 X-Google-Sender-Auth: 0c0a0765b3f773fd Message-ID: Subject: Re: Help with CouchDB query From: Chris Anderson To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Fri, Aug 7, 2009 at 10:54 AM, David Nolen wrote: > On Fri, Aug 7, 2009 at 12:40 PM, Chris Anderson wrote: >> >> Paginating over merged views is not trivial. For the case of 1 and 2, >> you could do that. For the case of 3 and 4, one way to implement this >> is by having a database per user, that contains their view of the >> world. Any documents they are interested would be replicated to that >> database, an nothing else. So it would make it easy to browse through >> documents from friends or groups the user follows. > > > Unfortunately for our application this could get exponential pretty quickly > so I'm not sure replicating all this data is doable? > > If filtering docs the user in interested in, into a smaller namespace >> is impractical, you will indeed have to do a lot of multi-key queries >> and merge them in your application code. Depending on load / >> performance you can probably do something like store the unpaginated >> complete set in memcached, and then dynamically paginate over it. > > > Would this work for different combinations of the four possibilities I've > described? Another limitation which I didn't describe is that these need to > sorted by date. It seems like a potential bottleneck to load the entire set > into memory, merge, and sort- especially since this will change, for > example, every time someone publishes a new document to a group. > > I don't know much about memcached, any good literature about integrating > this with CouchDB? > > >> Basically two different ways to do the same thing: putting the docs of >> interest in their own set and then paginate within it. The user-db >> approach gives you more flexibility with how to view the docs, but if >> you have users editing the same documents you'd have to do some >> legwork to make sure edits get replicated back "upstream" in a timely >> manner. Also, filtered replication is still a couple of Jira tickets >> away. > > > In our application documents are not edited by anyone but the owner. > > So is it not reasonable to run a couchdb-lucene query looking for the docs > that match the user's specifications? > This could be reasonable. I haven't used couchdb-lucene much so someone else should be able to help you better than I. > >> >> -- >> Chris Anderson >> http://jchrisa.net >> http://couch.io >> > -- Chris Anderson http://jchrisa.net http://couch.io