incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Help with CouchDB query
Date Fri, 07 Aug 2009 16:40:49 GMT
On Fri, Aug 7, 2009 at 8:05 AM, David Nolen<> wrote:
> So far I've really been loving CouchDB but I'm stumped on the best way to
> implement a particular query for our application. It's not clear to me
> whether what I'm trying to do can be done with views or is best handled by
> couchdb-lucene.
> Basically in our software users create documents which they can share with
> people. The user can choose to see documents in any combination of the
> following:
> 1. By url
> 2. By domain
> 3. By people the user is friends with
> 4. By groups the user belongs to
> This seems like four different views and 3 and 4 requires multiple keys to
> get the data. The problem here is that I'd like to be able to limit the
> results and specify a start index for paging. This doesn't seem possible to
> me but I'm probably missing something obvious :)

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.

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.

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

> Any help or insight much appreciated.
> Thanks,
> David

Chris Anderson

View raw message