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

Jump to bottom

Scripting: Ambiguous resolution of _doc.score #7043

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

Scripting: Ambiguous resolution of _doc.score #7043

jpountz opened this issue Jul 25, 2014 · 5 comments
Labels
>docs General docs changes v1.4.0.Beta1 v2.0.0-beta1

Comments

@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).
@dakrone
Copy link
Member

dakrone commented Jul 25, 2014

+1 on using _score instead of _doc.score!

@jpountz
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

@clintongormley clintongormley added the help wanted adoptme label Sep 8, 2014
@dakrone
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
Copy link
Contributor Author

jpountz commented Sep 11, 2014

+1

dakrone added a commit that referenced this issue Sep 11, 2014
@dakrone
[DOCS] Additional documentation for _score accessing
cccef6a 
Closes #7043

Conflicts:
	docs/reference/modules/scripting.asciidoc
@clintongormley clintongormley added >docs General docs changes and removed help wanted adoptme >bug labels Sep 11, 2014
brwe added a commit to brwe/elasticsearch that referenced this issue Sep 22, 2014
@brwe
script with _score: remove dependency of DocLookup and scorer
bca8f2e 
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 brwe mentioned this issue Sep 22, 2014
Closed
brwe added a commit that referenced this issue Sep 26, 2014
@brwe
script with _score: remove dependency of DocLookup and scorer
7feb742 
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
@brwe
script with _score: remove dependency of DocLookup and scorer
a4640b4 
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
@brwe
script with _score: remove dependency of DocLookup and scorer
6397167 
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
@loren
Support Elasticsearch 1.4.0
34b20ac 
- 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
@brwe
script with _score: remove dependency of DocLookup and scorer
d2e3f3a 
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
Copy link

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
Assignees
No one assigned
Labels
>docs General docs changes v1.4.0.Beta1 v2.0.0-beta1
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@dakrone @clintongormley @jpountz @stavrosicsd