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

Aggregation key can't be number #56402

Closed
rightaway opened this issue May 8, 2020 · 6 comments · Fixed by #56452
Closed

Aggregation key can't be number #56402

rightaway opened this issue May 8, 2020 · 6 comments · Fixed by #56452
Labels
:Analytics/Aggregations Aggregations >bug Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo)

Comments

@rightaway
Copy link

Elasticsearch version (bin/elasticsearch --version): 7.6.2

Plugins installed: []

JVM version (java -version): 13.0.2

OS version (uname -a if on a Unix-like system): archlinux

Description of the problem including expected versus actual behavior:

If you use a numeric key for a range aggregation you get an error. But string key works fine. Numeric keys should be accepted and turned into strings instead of failing.

Steps to reproduce:

aggs: {
  agg1: {
    range: {
      field: "agg1",
      ranges: [{ key: 1, from 1 }]
    }
  }
}

Provide logs (if relevant):

      type: 'x_content_parse_exception',
      reason: '[1:641] [range] failed to parse field [ranges]',
      caused_by: {                                                  
        type: 'parsing_exception',                                  
        reason: 'Failed to parse object: unknown field [key] found',
        line: 1,                                                    
        col: 641                                                    
      }
@rightaway rightaway added >bug needs:triage Requires assignment of a team area label labels May 8, 2020
@javanna javanna added the :Analytics/Aggregations Aggregations label May 8, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-analytics-geo (:Analytics/Aggregations)

@elasticmachine elasticmachine added the Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) label May 8, 2020
@javanna
Copy link
Member

javanna commented May 8, 2020

Please could somebody @elastic/es-analytics-geo have a look and verify whether limiting range keys to strings is a bug or rather a conscious decision?

@nik9000
Copy link
Member

nik9000 commented May 8, 2020

@polyfractal what do you think about this? I don't know enough about keys to have an opinion.

@polyfractal
Copy link
Contributor

I believe this is just a quirk of the old-style pull parser that Range still uses. If the token is a string, we check if it is potentially a key. If the token is a numeric value, we don't check for a key and thus throw the error.

It would be fairly trivial to cast a numeric key into a string and use that.

Note: We'll still need to return the key as a string, because default keys include the range (*-100), as well as BWC reasons. But I don't think there's a reason we can't accept numeric keys and cast to strings... that just feels like an oversight to me.

@polyfractal polyfractal removed the needs:triage Requires assignment of a team area label label May 8, 2020
@nik9000
Copy link
Member

nik9000 commented May 8, 2020

But I don't think there's a reason we can't accept numeric keys and cast to strings... that just feels like an oversight to me.

Gotcha!

nik9000 added a commit to nik9000/elasticsearch that referenced this issue May 8, 2020
This adds support for parsing numbers as range keys. They get converted
into a string, but we allow numbers.

While I was there I replaced the parser for `Range` with a
`ConstructingObjectParser` which will automatically add support for "did
you mean" style corrections on errors.

Closes elastic#56402
nik9000 added a commit that referenced this issue May 11, 2020
This adds support for parsing numbers as range keys. They get converted
into a string, but we allow numbers.

While I was there I replaced the parser for `Range` with a
`ConstructingObjectParser` which will automatically add support for "did
you mean" style corrections on errors.

Closes #56402
nik9000 added a commit to nik9000/elasticsearch that referenced this issue May 11, 2020
This adds support for parsing numbers as range keys. They get converted
into a string, but we allow numbers.

While I was there I replaced the parser for `Range` with a
`ConstructingObjectParser` which will automatically add support for "did
you mean" style corrections on errors.

Closes elastic#56402
nik9000 added a commit that referenced this issue May 11, 2020
This adds support for parsing numbers as range keys. They get converted
into a string, but we allow numbers.

While I was there I replaced the parser for `Range` with a
`ConstructingObjectParser` which will automatically add support for "did
you mean" style corrections on errors.

Closes #56402
@nik9000
Copy link
Member

nik9000 commented May 11, 2020

@rightaway I've landed this change in 7.x which will become 7.9.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Analytics/Aggregations Aggregations >bug Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants