On Mon, Aug 10, 2009 at 8:49 PM, Anand Chitipothu<[email protected]> wrote: > 2009/8/11 Paul Davis <[email protected]>: >> 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
