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

Scripting: Ambiguous resolution of `_doc.score` #7043

Closed
jpountz opened this Issue Jul 25, 2014 · 5 comments

Comments

Projects
None yet
4 participants
@jpountz
Copy link
Contributor

jpountz commented Jul 25, 2014

Some scripting languages don't make a difference between property access foo.bar and map lookups foo['bar']. This is an issue for the DocLookup class (which is the class behind the _doc variable and implements java.util.Map) since there are two ways that _doc.score can be resolved:

  1. DocLookup.getScore()
  2. DocLookup.get("score").

The interesting thing is that mvel translates _doc.score to getScore while Groovy seems to translate it to get("score"). So when trying to lookup the score in Groovy, you might see the following error:

GroovyScriptExecutionException[ElasticsearchIllegalArgumentException[No field found for [score] in mapping with types [index_name]].

For reference, if you encounter this issue, you can work around it by using _score instead of _doc.score. So maybe the way to go would be to deprecate _doc.score and make scripting engines expose the score via _score instead. I tend to find it cleaner as well since the score is not really a property of the document (it also depends on the query).

@jpountz jpountz added bug labels Jul 25, 2014

@dakrone

This comment has been minimized.

Copy link
Member

dakrone commented Jul 25, 2014

+1 on using _score instead of _doc.score!

@jpountz

This comment has been minimized.

Copy link
Contributor Author

jpountz commented Jul 25, 2014

For reference, here is a confirmation that in case of a conflict Groovy prefers the map access: http://groovy.329449.n5.nabble.com/Property-resolution-clash-for-Map-subclasses-td5717713.html

@dakrone

This comment has been minimized.

Copy link
Member

dakrone commented Sep 10, 2014

@jpountz I looked and we already support _score in Groovy scripts (there's a test for it too). So I think all that needs to be done for this is to add documentation about _score being the preferred method instead of _doc.score. Does that sound good to you?

@jpountz

This comment has been minimized.

Copy link
Contributor Author

jpountz commented Sep 11, 2014

+1

dakrone added a commit that referenced this issue Sep 11, 2014

[DOCS] Additional documentation for _score accessing
Closes #7043

Conflicts:
	docs/reference/modules/scripting.asciidoc

@dakrone dakrone closed this in 1dd2688 Sep 11, 2014

@clintongormley clintongormley added >docs and removed help wanted >bug labels Sep 11, 2014

brwe added a commit to brwe/elasticsearch that referenced this issue Sep 22, 2014

script with _score: remove dependency of DocLookup and scorer
As pointed out in elastic#7487 DocLookup is a variable that is accessible by all scripts
for one doc while the query is executed. But the _score and therfore the scorer
depends on the current context, that is, which part of query is currently executed.
Instead of setting the scorer for DocLookup
and have Script access the DocLookup for getting the score, the Scorer should just
be explicitely set for each script.
DocLookup should not have any reference to a scorer.
This was similarly discussed in elastic#7043.

This dependency caused a stackoverflow when running script score in combination with an
aggregation on _score. Also the wrong scorer was called when nesting several script scores.

closes elastic#7487

brwe added a commit that referenced this issue Sep 26, 2014

script with _score: remove dependency of DocLookup and scorer
As pointed out in #7487 DocLookup is a variable that is accessible by all scripts
for one doc while the query is executed. But the _score and therfore the scorer
depends on the current context, that is, which part of query is currently executed.
Instead of setting the scorer for DocLookup
and have Script access the DocLookup for getting the score, the Scorer should just
be explicitely set for each script.
DocLookup should not have any reference to a scorer.
This was similarly discussed in #7043.

This dependency caused a stackoverflow when running script score in combination with an
aggregation on _score. Also the wrong scorer was called when nesting several script scores.

closes #7487
closes #7819

brwe added a commit that referenced this issue Sep 26, 2014

script with _score: remove dependency of DocLookup and scorer
As pointed out in #7487 DocLookup is a variable that is accessible by all scripts
for one doc while the query is executed. But the _score and therfore the scorer
depends on the current context, that is, which part of query is currently executed.
Instead of setting the scorer for DocLookup
and have Script access the DocLookup for getting the score, the Scorer should just
be explicitely set for each script.
DocLookup should not have any reference to a scorer.
This was similarly discussed in #7043.

This dependency caused a stackoverflow when running script score in combination with an
aggregation on _score. Also the wrong scorer was called when nesting several script scores.

closes #7487
closes #7819

brwe added a commit that referenced this issue Sep 26, 2014

script with _score: remove dependency of DocLookup and scorer
As pointed out in #7487 DocLookup is a variable that is accessible by all scripts
for one doc while the query is executed. But the _score and therfore the scorer
depends on the current context, that is, which part of query is currently executed.
Instead of setting the scorer for DocLookup
and have Script access the DocLookup for getting the score, the Scorer should just
be explicitely set for each script.
DocLookup should not have any reference to a scorer.
This was similarly discussed in #7043.

This dependency caused a stackoverflow when running script score in combination with an
aggregation on _score. Also the wrong scorer was called when nesting several script scores.

closes #7487
closes #7819

@clintongormley clintongormley changed the title Scripting: ambiguous resolution of `_doc.score` Scripting: Ambiguous resolution of `_doc.score` Sep 26, 2014

loren added a commit to GSA/asis that referenced this issue Nov 10, 2014

Support Elasticsearch 1.4.0
- Changed "doc.score" and "_doc.score" to "_score", per elastic/elasticsearch#7043
- Upgraded gems while I was at it (latest sidekiq-unique-jobs requires explicit inclusion of mock_redis gem)

Closes #6

mute pushed a commit to mute/elasticsearch that referenced this issue Jul 29, 2015

script with _score: remove dependency of DocLookup and scorer
As pointed out in elastic#7487 DocLookup is a variable that is accessible by all scripts
for one doc while the query is executed. But the _score and therfore the scorer
depends on the current context, that is, which part of query is currently executed.
Instead of setting the scorer for DocLookup
and have Script access the DocLookup for getting the score, the Scorer should just
be explicitely set for each script.
DocLookup should not have any reference to a scorer.
This was similarly discussed in elastic#7043.

This dependency caused a stackoverflow when running script score in combination with an
aggregation on _score. Also the wrong scorer was called when nesting several script scores.

closes elastic#7487
closes elastic#7819
@stavrosicsd

This comment has been minimized.

Copy link

stavrosicsd commented Oct 9, 2015

Hello to everyone,

I just upgraded elasticsearch from 1.3.4 to 1.4.4 and I am getting the aforementioned error:
org.elasticsearch.script.groovy.GroovyScriptExecutionException: ElasticsearchIllegalArgumentException[No field found for [score] in mapping with types [type_name]]

I have read the initial workaround but I did not understand unfortunately how to proceed.
Any assistance would be very helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.