couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Proposal for a new and powerful "keymask" option in views
Date Mon, 07 Mar 2016 16:37:12 GMT

> On 07 Mar 2016, at 01:27, Adam Kocoloski <> wrote:
> Hi Constantin, this is definitely the right list :)
> Have you seen the work on the new “Mango” query processor? The README on the repo
is probably the best resource:
> If the elements of your key array are pulled directly from fields of the document then
it would be possible to execute a keymask using a _find invocation. The Mango query processor
will use the index you create and then do an Erlang-based filter of the remaining rows to
satisfy the exact query. There are a few limitations to Mango at the moment:
> - Mango wants its own indexes, it doesn’t know how to incorporate user-defined MR views

Sorry for the derail, but this sounds fascinating. *could* Mango updated to use user-defined
MR views (given they adhere to any Mango specific requirements, not just any MR views).


> - The indexes do not allow for any custom processing of the document fields that are
> - Reduce functions are not supported
> I’d be curious to hear if that would address your use case. Cheers,
> Adam
>> On Mar 6, 2016, at 3:42 AM, Constantin Teodorescu <> wrote:
>> Hello all, a quick use case for a new "keymask" option in views:
>> We have a view with keys as array like [ k1 , k2 , k3, k4]
>> we're using, most of the time, reduces and data processing using:
>> "startkey": [ k1 , ""],
>> "endkey": [ k1 , "\ufff0"]
>> Sometimes I feeld that it would be just fantastic to have a filtering
>> option on keys like:
>> "startkey": [ k1 , ""],
>> "endkey": [ k1 , "\ufff0"],
>> "keymask": [ null, null, "desired k3 value" , null],
>> "reduce": false,
>> that would filter anything between the startkey and endkey WHERE k3 =
>> "desired k3 value"
>> Sometimes, there is a need for more than a unique design of the view tree
>> keys, to access data grouped in another way.
>> Of course, we can acomplish that:
>> - defining a new map/reduce function [k1,k3,k2,k4] (waste of disk space,
>> time consuming)
>> - using a _list function that will do the trick (slower, that's what I am
>> doing now)
>> But introducing the "keymask" option in view, filtering rows right at the
>> core of CouchDB, in Erlang, without expensive traffic to the query server,
>> would speed things a lot. And I'm thinking that it wouldn't be so hard to
>> do it. I hope ... ;-)
>> Of course, "keymask" will be usable ONLY when "reduce":false , otherwise
>> reduce values will be garbage!
>> Constantin Teodorescu
>> A long time watcher, fan and user of CouchDB, even in the nation-wide
>> animal identification system in Romania and farmers subsidies.
>> Now working on a "killer app",  a new and astonishing small business
>> accounting and information management system in CouchDB!
>> P.S. I'm not sure that this is the right mailing list to address this
>> proposal but ... maybe it's interesting for anyone!

View raw message