couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: sort by reduce value
Date Tue, 11 Aug 2009 06:44:04 GMT
On Mon, Aug 10, 2009 at 8:49 PM, Anand Chitipothu<anandology@gmail.com> wrote:
> 2009/8/11 Paul Davis <paul.joseph.davis@gmail.com>:
>> Anand,
>>
>> No, not at the moment. I and others have looked at implementing the
>> necessary bits but there are some complex gotchyas when implementing
>> some of the key bits. Specifically the step of persisting group=true
>> output to a second btree is fairly tangly while trying to maintain the
>> current API.
>
> What if we treat the output a view as another virtual database with
> ids as keys of the view result.
>
> If we make
> GET /db/_design/count/_db/by_count/foo
> same as
> GET /db/_design/count/_view/by_count?key=foo
>
> Then we can add second level design docs at
> /db/_design/count/_db/by_count/_design/sort. and that can be queried
> as
> GET /db/_design/count/_db/by_count/_design/sort/_all?key=foo.
>
> Does it make sense? Is this something that you have already tried?
>
> Anand
>

Anand,

I think it makes sense.

I would like to see that feature. However, I'd prefer to make the API
more descriptive of the underlying operations.

Because you can only build a sorted reduce by copying it to another
index anyway, storing that index in another db is more straightforward
and flexible than making the current view queries recursive.

Trivial chaining (Hadoop style) is what you'd get from a copy-to-db
semantics. You could still build query chains, and it'd be relatively
easy to make an IDE for that in Futon.

If you're interested in developing, join the dev@ list and make your
voice heard.

Chris

-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message