Use actual index for validation instead of .kibana

[ahardy]

Following the basic parent/child setup here. ES 1.4.2 & K 4-beta3

• Add parent-child mapping to index

PUT /parent-child
{
  "mappings": {
    "branch": {},
    "employee": {
      "_parent": {
        "type": "branch" 
      }
    }
  }
}

• Index parent and child

PUT /parent-child/branch/london
{
  "name": "London Westminster", 
  "city": "London", 
  "country": "UK" 
}

PUT /parent-child/employee/1?parent=london
{
  "name":  "Alice Smith",
  "dob":   "1970-10-24"
}

• Find parent by children

GET /parent-child/branch/_search
{
  "query": {
    "has_child": {
      "type": "employee",
      "query":  {"match_all": {} }
    }
  }
}

• Find children by parent

GET /parent-child/employee/_search
{
  "query":{
  "has_parent": {
  "type": "branch", 
  "query": { 
    "match": {
      "country": "UK"
    }}}}}

All queries work as expected against Elasticsearch

• Execute Json query within Kibana search box fails

{"has_child": {"type": "employee", "query":  {"match_all": {} }}}

error: "org.elasticsearch.index.query.QueryParsingException: [.kibana] [has_child] No mapping for for type [employee]"
index: ".kibana"
valid: false

{"has_parent": {"type": "branch", "query": { "match": {"country": "UK"}}}}
error: "org.elasticsearch.index.query.QueryParsingException: [.kibana] [has_parent] query configured 'parent_type' [branch] is not a valid type"
index: ".kibana"
valid: false

[krijnmossel]

Had request for this functionality from Masai Technology.

[ajrasch]

Is anyone working on this? Thanks!

[spalger]

It should be noted that the validator on the dashboard will need to validate against all of the indices that the filter will be included in. Unfortunately, we will need to validate each index pattern separately to ensure that queries run against the index patterns in isolation will not fail (for whatever reason) and the error messages will need to identify the index pattern they fail against.

[rashidkpc]

There's an additional problem here. The query validator requires the index name be passed in the URL. This is fine for non-timestamp indices, but for timestamped indices we're going to end up with a really huge list of indices which is going to exceed the elasticsearch URL length limit

We COULD just get the first index in the list and only validate against that, but its a poor solution. If we are validating a complex query such as a geo or parent/child, and one of the indices in the list is missing the field, the query is going to fail and we're not going to know why.

On top of all that, the validator is a hack to make sure we don't fail all shards just because of a typo. We shouldn't even need it. The real solution here is to not even use the query validator, and fix the error messages in elasticsearch so we know why a request failed: elastic/elasticsearch#3303

[antcodd]

_validate appears to support wildcards in Multiple Indices syntax just fine, at least as of Elasticsearch 1.4.5. It simply returns an array of validation results, one for each matching index.

Why not just pass the index wildcard directly as the index name for now? There even seems to be some code for this in components/validate_query/validate_query.js, but no plumbing for $scope.queryInput. This would also have the benefit of checking field type mapping (a little care might be needed for scripted fields depending on how these work in Kibana).

This issue (along with #1084 and the lack of arbitrary custom aggregation JSON) severely limit the applications of Kibana by making it impossible, as far as I can tell, to visualize relationships in any manner without denormalizing every field on the dashboard.

[ajrasch]

ANy progress on supporting has_parent and has_child filters in the recent Kibana versions?

[tbragin]

As a result of not checking the actual index, the geo distance filter (and perhaps others) don't currently work, if you paste the Query DSL into the Kibana search bar:

{
    "filtered": {
      "query": {
        "match_all": {}
      },
      "filter": {
        "geo_distance": {
          "distance": "200km",
          "coordinates": {
            "lat": 40,
            "lon": -70
          }
        }
      }
    }
  }

Here is the full DSL from Sense which works directly against Elasticsearch 1.6 ("geo.coordinates" field has type "geo_point").

GET logstash-2015.05.18/_search
{
  "query": {
    "filtered": {
      "query": {
        "match_all": {}
      },
      "filter": {
        "geo_distance": {
          "distance": "200km",
          "coordinates": {
            "lat": 40,
            "lon": -70
          }
        }
      }
    }
  }
}

[philbb]

I'm seeing the same problem with geohash_cell.
When I type the following into the Kibana search bar {"filtered":{"filter" : {"geohash_cell": {"location": "u33dd"}}}}
I get: QueryParsingException failed to find geo_point field [location]

[rashidkpc]

Closing this as we've removed query validation now that elasticsearch 2.0 has structured errors.