Inline.
On Nov 15, 2013, at 10:51 AM, Jens Alfke wrote: > > On Nov 15, 2013, at 10:03 AM, Jeff Lowery <[email protected]> wrote: > >> What I would like is the ability to specify a view that takes a key/value >> map. Behind that view would be indexes for n number of k-v pairs in that >> map in any permutation order. E.g.: > > A view _is_ an index. The emit() function is literally adding individual > key/value pairs to the generated b-tree index. If you want multiple indexes, > you create multiple views. You're misreading me. I know that. > > It wouldn’t be hard to write a wrapper function in your code to generate the > views for the multiple permuted indexes you’re asking for. I know that as well. > >> I realize that the permute param results in a factorial # of views >> (permuting 5 k-v pairs = 120 views); what is the practical limit? I assume >> it would depend on the # of documents in a db. > > Yeah, this would become ridiculous pretty quickly. Especially since I’d wager > that most clients would only want a handful of the huge number of indexes > produced. It’s much better to explicitly generate the indexes you need, since > there is significant overhead to producing and updating them. And that was the point of the question. In my little problem space, I have unordered navigation that requires lookup on each of anywhere from 1-6 entries. I can make this work in CouchDB, pretty much as I outlined above. What I asked for was the ability to specify this directly in the database. I don't have to have it, but I thought it worth posting the thought. > > —Jens
