Query / filter/ aggregation "X" is not supported

[danpaz]

Right now bodybuilder depends on having a definition for every filter/query/aggregation in the elasticsearch query dsl (which is a lot). This works, and gives a high degree of control over how to construct each filter/query/aggregation clause. However,

• The dsl is a moving target. It is not sustainable to update bodybuilder in lockstep with elasticsearch as the dsl changes.
• It can be frustrating if bodybuilder doesn't support a particular filter/query/aggregation, and someone either has to make a PR and wait for a patch or drop bodybuilder altogether.
• Many issues have been created to address missing filters/queries/aggregations: Add filter aggregations #64 Addition of bucket scripts #63 date_range not supported #53 Add match phrase prefix query #42 +++

Proposals

Some ideas I had to improve this:

• Allow custom filter/query/aggregation clauses. Maybe it could look something like:

new Bodybuilder().filter('custom', { ... })
or
new Bodybuilder().rawFilter({ ... })

This way bodybuilder can continue to be useful while users wait for a PR to add their definition is merged.

• Generalize the filter/aggregation/query builders such that maybe we don't need definitions for individual clauses at all. Most clauses follow a predictable structure. Example:

.filter(<type>, <field>, <value>)
becomes
{
  <type> {
    <field>: <value>
  }
}

// Example
.filter('term', 'user', 'kimchy')
becomes
{
  term: {
    user: 'kimchy'
  }
}

Still thinking these ideas through and looking for feedback from anyone on this!

[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