I got this working afternoon. Seems like couchdb-lucene is the way to go for what I'm describing. It was easy to set up and is cleanly integrated with CouchDB.
On Fri, Aug 7, 2009 at 2:04 PM, Chris Anderson <[email protected]> wrote: > On Fri, Aug 7, 2009 at 10:54 AM, David Nolen<[email protected]> > wrote: > > On Fri, Aug 7, 2009 at 12:40 PM, Chris Anderson <[email protected]> > 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 >
