Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Add fielddata accessors (.value/.values/.distance()/etc) #18169
Currently fields in painless are recommended to be accessed as
Instead we should work closer to the current syntax
This has other benefits, it means we expose more of the scripting api (see https://www.elastic.co/guide/en/elasticsearch/reference/master/modules-scripting-groovy.html#_doc_value_properties_and_methods)
I TODO'd whitelisting any joda-time stuff to be a separate change.
Field loads for this common
I cutover the integration tests and docs to use this syntax.
@rmuir should i move these properties/methods (https://www.elastic.co/guide/en/elasticsearch/reference/master/modules-scripting-groovy.html#_doc_value_properties_and_methods) back to the general scripting section instead of leaving them in groovy? or perhaps add them to the painless docs?
@clintongormley I don't know what to do here!
Expressions basically exposes what looks like a subset of this API to users, but its a lie: it in fact bypasses the whole thing entirely, and the expressions API is inconsistent in random annoying ways: e.g.
On one hand, I think painless needs to support this API, to get people off of groovy. On the other hand, I'm not sure if we want to declare it front-and-center "the scripting api", because its not very good. I don't mean this in an offensive way, the API is both slow and bad, its just a fact. Expressions is 2x faster than anything else because it bypasses it completely.
One reason it is cumbersome and slow is that it exposes a document's fields as always being multivalued lists, but its not clear to me user's even care about multi-valuedness whatsoever: (4ddf916)
There are also tons and tons of geo functions, but many of these look very obscure. I think its ok to continue supporting them, to not break anyones scripts, but do we really have to document all the obscure stuff?
I think it makes things overwhelming. An easy win might be to try to drop some of these obscure methods from the documentation. I think all the multi-valued methods (e.g.
referenced this pull request
May 8, 2016
I do understand that we need to provide an API which is similar in it's functionality but putting ourself into the position of building painless on top of an already known problem sounds weird to me. I think we can build a new API that allows for good performance based on a subset of the current API and deprecate the current one. All other scripting languages can potentially have access to both such that folks can move gradually but we can build a new and fast API? Does this make sense and / or is this feasible at all?