Strict query parsing on percolators and alias filters

[clintongormley]

Today, if we create a filtered alias or a percolator query which references a field that is not yet mapped, the field is interpreted as a string.

This is a problem when (eg) the user then indexes a document where the field is really numeric or a date. Any existing filters or percolator queries will not work correctly until the cached filter/query is regenerated (eg after a restart).

Instead, we should support a "strict" query parsing mode which throws an error if an unmapped field is referenced.

[clintongormley]

See #6572

[jpountz]

One option might be to make the filter evaluation lazy until fields are mapped but that would add significant complexity/overhead so I think strict query parsing would be the way to go! Maybe we could have a helper method on the context to resolve fields that would return null when strict parsing is disabled and raise an error otherwise?

[clintongormley]

Also see #6110 - term lookup filters should verify that the doc actually exists when the filter is instantiated.

[s1monw]

@martijnvg did this not get closed or is it only partially resolved ? Anyway can we close or push to 1.5?

[martijnvg]

@s1monw The strict field resolution is already pushed. I forgot that there was an issue for this!

@clintongormley Regarding the terms lookup filter, the #6928 PR doesn't cover this since it only takes care of unmapped fields in the mapping. I think we should open a different issue for this? Also the geo_shape filter with is referring to an indexed shape suffers from the same problem.

[s1monw]

@martijnvg can we close it?

[martijnvg]

@clintongormley Ow wait, the geo_shape filters fail if an indexed shape document doesn't exist. I think we should do the same for the terms lookup filter? (right now it silently ignores it by not matching anything)

[martijnvg]

@s1monw yes, imo we can close this.

[andreasch]

Shouldn't alias filters at least allow referencing fields that are internal like _type, _id or _routing?

[clintongormley]

@andreasch this sounds like it should be a new issue?

[andreasch]

@clintongormle I believe it is a new issue and I can go create one if it makes sense.

We have a multi-tenant implementation where the routing value is equal to the tenant name and routing is always required and used.

We also use alias filtering as described here:
http://www.elastic.co/guide/en/elasticsearch/guide/master/faking-it.html

For our alias filters we have something like this:

{
    "term":{
        "_routing":"tenantName"
    }
}

However, Elasticsearch versions 1.4 and after do not allow for such an alias filter to be created.

[clintongormley]

@andreasch ok - I thought you meant something else. You can create filters like that today, but you need to set the _routing field to be indexed. (This will be done by default in v2). See http://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-routing-field.html#_store_index