Allow expressions to compute keys

[larsga]

Issue #55 demonstrates that there might be a need for being able to write objects like this:

{
  .foo : .bar,
  "something" : .else
}

There doesn't seem to be any clear reason why this couldn't be supported.

[ngsoftwaredev]

That feature would help me so much!

[larsga]

Could you show an example of how you would use it? That would be helpful for me.

[ngsoftwaredev]

Sure!

One use case I have is to generate Elasticsearch queries from a business-specific DSL, using JSLT, which allows me for far more sophisticated templating than Elasticsearch native templating (based on mustache.js)!

Here's a sample JSLT :

let searchFields = [ "title", "author", "category" ]
let facetFields = [ "category", "thema" ]
let searchText = .text

{
  "query": {
    "dis_max": {
      "tie_breaker": 1,
      "queries": [ for ($searchFields)
        {
          "fuzzy": {
            . + ".lang"  : {
              "value": $searchText,
              "fuzziness" :     2,
              "prefix_length" : 1,
              "max_expansions": 100
            }
          }
        }        
      ]
    }
  },
  "highlight": {
    "fields": { for ($searchFields)
      . + ".lang": { "number_of_fragments": 1 }
    }
  },
  "aggs": {
    for ($facetFields) {
      let field = .
      $field : {
        "terms": {
          "field": $field,
          "size": 20
        }
      }
    }
  }
}

This does not compile. This is only a very simple query, it could be much more complex, but basically I always have to use a field name as a key to specifiy some operation on it, be it a search operation, a highlight, an aggregation.

Currently I have to build a JSON string instead and the use the from-json function.

[larsga]

This makes sense. Thank you! Yes, I think we should add support for this. I'll see if I can get it done.

[larsga]

Now I find I need this feature myself.

[larsga]

Some issues that need to be worked out.

Dynamic keys in objects that use the object matcher. Since we don't know at compile-time what keys are defined in the matcher the matching behaviour becomes more complex. Possible solution: forbid dynamic keys in matchers.

What if the key expression produces something that's not a string? We consider this an error.

What if the key expression ends up producing a duplicate key? Duplicate literal keys are forbidden at the moment. Consider this an error?

[larsga]

Fixed in commit 7342c95