Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[indexPattern/field] remove "bucketable" property of fields #5806

Merged
merged 1 commit into from
Jan 19, 2016

Conversation

spalger
Copy link
Contributor

@spalger spalger commented Jan 5, 2016

Fixes #3335
Fixes #5914

We currently setup a bucketable property on every field in order to detect if the field can be used in a bucket aggregation. When it was discovered that our condition was incorrect we decided that we wanted to lean on Elasticsearch's new structured error messages rather than trying to maintain a secondary implementation of the validation in Kibana.

We currently setup a bucketable property on every field in order to detect if the field can be used in a bucket aggregation. When it was discovered that our condition was incorrect we decided that we wanted to lean on Elasticsearch's new strctured error messages rather than trying to maintain a secondary implementation of the validation in Kibana.
@thefab
Copy link

thefab commented Jan 7, 2016

not sure to understand why but with latest released kibana and ES:

  • with my mapping, "non string" fields are marked as "non indexed" in indices settings (for example the @timestamp date field)
  • but of course, I can do aggregations and searches on these fields (which are indexed)
  • on the discover page, the histogram (on @timestamp date field) is ok for example
  • but impossible to reproduce a date histogram on visualize page (because the @timestamp field is considered as "non indexed")
  • dropping anything, refreshing indices on kibana... don't help

this pull request saved my day (but the root problem is still here: why my "non string" fields are considered as non indexed ?)

an idea ? or I open a new issue (about the root cause) ?

@thefab
Copy link

thefab commented Jan 7, 2016

corresponding simple mapping template:

{
    "template": "nginx-*",
    "mappings": {
        "nginx": {
            "properties": {
                "@timestamp": {"type": "date"},
                "source_host": {"type": "string", "index": "not_analyzed"},
                "source_path": {"type": "string", "index": "not_analyzed"},
                "module": {"type": "string", "index": "not_analyzed"},
                "user_id": {"type": "string", "index": "not_analyzed"},
                "user_agent": {"type": "string", "index": "not_analyzed"},
                "uri": {"type": "string"},
                "uri_path": {"type": "string", "index": "not_analyzed"},
                "status": {"type": "integer"},
                "root_id": {"type": "string", "index": "not_analyzed"},
                "request_id": {"type": "string", "index": "not_analyzed"},
                "mother_id": {"type": "string", "index": "not_analyzed"},
                "request_length": {"type": "long"},
                "reply_length": {"type": "long"},
                "recursion": {"type": "string", "index": "not_analyzed"},
                "processing_ms": {"type": "string", "index": "not_analyzed"},
                "method": {"type": "string", "index": "not_analyzed"},
                "from": {"type": "string", "index": "not_analyzed"},
                "client_priority": {"type": "string", "index": "not_analyzed"},
                "duration": {"type": "double"}
            }
        }
    }
}

@rashidkpc
Copy link
Contributor

I don't understand why this was merged? I didn't review it, and this definitely should not be in 4.5.0 anyway?

@rashidkpc
Copy link
Contributor

@spalger Who reviewed this?

@spalger spalger deleted the fix/bucketableCondition branch February 25, 2016 22:48
@tbragin tbragin mentioned this pull request Mar 16, 2016
3 tasks
@spalger spalger removed the v4.5.0 label Mar 17, 2016
@spalger
Copy link
Contributor Author

spalger commented Mar 17, 2016

@rashidkpc to be honest, I'm not sure who reviewed it, but I'm confident that I didn't just merge it... It didn't get backported to 4.5 so no worries there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants