Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of nickretallack@gmail.com
 designates 209.85.217.12 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=iFn6muNb8VBvyF+1yTAYn94vlfW0UxKKSyFZE6EOIy7Ev3GIPdzGwLWeRj36ZxNe0l
         y+WySa55jJhUBwHgtOaXvytYpp77+/2hEY3ICNRTVb89pMvkserA+sknMI/3zj8Mdzvc
         L+N+M4ZpPBlhvCzA8h33OmzwfPuoh7Vm/RUZI=
Message-ID: <66e809970812031446n5c8ed530v4c85cd073aa15702@mail.gmail.com>
Date: Wed, 3 Dec 2008 14:46:53 -0800
From: "Nicholas Retallack" <nickretallack@gmail.com>
To: couchdb-user@incubator.apache.org
Subject: Re: multiple keys and sorting
In-Reply-To: <e282921e0811170726u41086879s84797b5534b5701@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_111352_26344362.1228344413558"
References: <66e809970811161954x6a10ce01u14ded1cb11cffb60@mail.gmail.com>
	 <e282921e0811170726u41086879s84797b5534b5701@mail.gmail.com>

------=_Part_111352_26344362.1228344413558
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I ended up just doing all the queries every time, sorting the results, and
clipping them.  That means I fetched all the pages on each page.  It was
fast enough.

An easy improvement would be to do the multiple queries, sort them, and then
cache that somewhere similar to a view in case the user asks for another
page.  It would be great if that cache also knew when it should be
invalidated -- that is, when the underlying views changed.  Also, it would
be even cooler if it calculated how often this cached set was needed versus
others, so one-offs didn't stick around too long.

These second level caches could be query-able just like views are, but one
level removed.  We could even specify them with permanent javascript methods
so you could query on them instead of the underlying views.  What do you
guys think?

On Mon, Nov 17, 2008 at 7:26 AM, Chris Anderson <jchris@apache.org> wrote:

> On Sun, Nov 16, 2008 at 7:54 PM, Nicholas Retallack
> <nickretallack@gmail.com> wrote:
> > We could do 3 queries anyway, each with the maximum number of documents
> on
> > the page, then sort them ourselves and throw away the extras.  This gets
> > messy fast though, when you try to keep track of where to start the
> second
> > page in each query.
> >
> > What would you guys suggest?
> >
>
> I think the smart money would be in working this way, with keys like
> ["joe", "2008-11-1"] and running 3 queries. You're right about the
> tough part being paginating the subsequent pages, because you don't
> know where to start with each one until they've been merged and
> sorted.
>
> Unless you can come up with a collation key that does the work
> magically ("dude_groups") any kind of multi-range extension to couch
> would have the same problems your application is facing. This is the
> type of thing that belongs in a library, I think.
>
> An interesting place to put the library might be as an _external
> action, if you really want to keep it out of the client, but external
> _actions have the dubious distinction of using server resources to do
> what could be equally well done on the client. (Also they are not yet
> in CouchDB trunk.)
>
> Chris
>
> --
> Chris Anderson
> http://jchris.mfdz.com
>

------=_Part_111352_26344362.1228344413558--