New mango operator proposal : match keys of a map

[borkowmichal]

Overview

Proposition of a new Mango query operator that allows to query on the keys of a map.
It is related to the already existing $elemMatch but instead on the elements of an array it is applied on the keys
of a map.

For the name of the operator I don't know what's best suited, I used $keyMapMatch.

Related Issues or Pull Requests

apache/couchdb-documentation#574

Checklist

• Code is written and works correctly
• Changes are covered by tests
• Any new configurable parameters are documented in rel/overlay/etc/default.ini
• A PR for documentation changes has been made in https://github.com/apache/couchdb-documentation

[janl]

Approved, but I’d like to have one more +1 just to make sure :)

[davisp]

This looks to be implemented correctly but I've got two questions. Is there a motivating use case we should document? The example in the test is equivalent to the $exists operator and I'm not personally seeing an obvious other use for this, though I'd wager that's just my lack of imagination this early in the morning.

Secondly, the logic currently has a bit of an implicit $or going on since any key that matches would cause this to match. So testing for the lack of a key or some sort of negative condition wouldn't work. I wonder if we couldn't make it slightly more generalized if we matched the sub-selector against an array of keys?

[janl]

The ergonomics of an $exists with a dynamic key name are somewhat awkward, I bumped on that a few times before until I remember that’s an option. That’s why I liked this a little more obvious variant.

[borkowmichal]

For the use case, the example is not representative in itself indeed.
Here's one of the use cases we have:

Given this partial representation of a document that has delegations (represented by the map keys), we would like to get all documents with a specific delegation. We also make more complex queries, and we use JSON indexes.

{
    "foo": "bar",
    "delegations": {
        "c4d16e9e-4da0-4bb0-8be1-2852e4618386": [
            {
                "owner": "c4d16e9e-4da0-4bb0-8be1-2852e4618386",
                "delegatedTo": "c4d16e9e-4da0-4bb0-8be1-2852e4618386",
                "key": "foo"
            }
        ],
        "c314e17b-17f2-4b7d-ad0c-bcb173f23d58": [
            {
                "owner": "20e14384-4115-48f9-aec9-0ae667826cd2",
                "delegatedTo": "c314e17b-17f2-4b7d-ad0c-bcb173f23d58",
                "key": "bar"
            }
        ],
        "f5d6776a-bf52-4f94-9d0c-ba4e700433ec": [
            {
                "owner": "149aca84-1fb6-40a6-82f2-cec9a3c4440d",
                "delegatedTo": "f5d6776a-bf52-4f94-9d0c-ba4e700433ec",
                "key": "x"
            }
        ]
    }
}

In this situation the $exists operator doesn't allow us to use an index on the delegations field to make this kind of queries; we get a warning that the index was not used.

That's what motivated us to create this operator.

[davisp]

@janl @borkowmichal Ah! Gotchya, that makes perfect sense.

[davisp]

+1