Query / filter/ aggregation "X" is not supported

[danpaz]

Query / filter/ aggregation "X" is not supported

[johannes-scharlach]

Big 👍 for custom aggregations. The syntax there is less predictable and prior to creating #64, that was the feature I was looking for.

With filters & queries: My feeling is that the syntax there is very predictable, so I'd generally expect a .filter(<type>, <field>, <value>) API. The <type> can even be generically converted from camelCase and kebab-case to snake_case. (lodash has some convenience functions around that)

[danpaz]

Starting to look at what it would take to put together a generic api for queries/filters, I started collecting notes trying to categorize all the different forms a query clause can take.

Query/Filter structures I've observed:

No field (Match All query):

{
  <type>: {}
}
// example:
{
  match_all: {}
}

Field but no value:

{
  <type>: {
    field: <field>
  }
}
// or
{
  <type>: {
    value: <field>
  }
}
// examples:
{
  exists: {
    field: 'some_field_name'
  }
}
{
  type: {
    value: 'some_type_name'
  }
}

Field with value:

{
  <type>: {
    <field>: <value>
  }
}
// examples:
{
  term: {
    user: 'kimchy'
  }
}
{
  terms: {
    user: ['kimchy', 'rob']
  }
}

Field with value and more options:

{
  <type>: {
    <field>: <value>,
    <a>: <b>,
    <c>: <d>,
    ...
  }
}
// example:
{
  geo_distance: {
    distance: '12km',
    point: {
      lat: 40,
      lon: 20
    }
  }
}

Join queries such as nested query:

{
  <type>: {
    path: <parent_field>,
    query: {
      <type>: {
        '<parent_field>.<child_field>': <value>
      }
    }
  }
}
// examples:
{
  nested: {
    path: 'obj1',
    query: {
      match: {
        'obj1.color': 'blue'
      }
    }
  }
}
{
  has_child: {
    type: 'blog_tag',
    query: {
      term: {
        tag: 'something'
      }
    }
  }
}
// perhaps these can be treated as a special case of nested queries?

[danpaz]

bodybuilder 2 is in beta! https://github.com/danpaz/bodybuilder/releases/tag/v2.0.0-beta.1