[
https://issues.apache.org/jira/browse/SOLR-18151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18066373#comment-18066373
]
David Smiley commented on SOLR-18151:
-------------------------------------
It's been many years since Solr 7.2. I'm skeptical anything further should be
done.
If I'm not mistaken, the behavior is impacted by luceneMatchVersion in
solrconfig.xml... thus if you need to upgrade Solr within the major release say
7.0 to 7.X then you can continue to use an older luceneMatchVersion if you are
not yet in a position to comply with the compatibility matters listed in the
upgrade notes.
> edismax: _query_ disallowed via uf is interpreted as literal text without
> explicit signal
> -----------------------------------------------------------------------------------------
>
> Key: SOLR-18151
> URL: https://issues.apache.org/jira/browse/SOLR-18151
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
> Affects Versions: 8.9, 9.10.1
> Environment: Solr version: 9.10.1
> Also observed in: 8.9.0
> Deployment: Local standalone instance built from source
> Query parser: edismax
> Collection: Minimal test collection with a single text field
> Example document:
> id: 1
> text: "laptop apple macbook"
> Debugging enabled via debugQuery=true.
> Reporter: parveen saini
> Priority: Minor
> Labels: edismax, queryparser
>
> When using {{{}defType=edismax{}}}, the {{_query_}} pseudo-field requires
> explicit inclusion in the {{uf}} parameter.
> If {{_query_}} is not included in {{{}uf{}}}, a query such as:
> q={_}query{_}:"\{!edismax qf=text}iphone"
> defType=edismax
> does not execute the nested subquery. Instead, {{_query_}} is interpreted as
> literal user text and tokenized by edismax.
> Reproduction request:
> curl -iG "[http://localhost:8983/solr/repro/select]";
> --data-urlencode "defType=edismax"
> --data-urlencode 'q={_}query{_}:"\{!edismax qf=text}iphone"'
> --data-urlencode "debugQuery=true"
> Response excerpt:
> HTTP/1.1 200 OK
> debugQuery output shows the query being interpreted as literal tokens:
> rawquerystring: {_}query{_}:"\{!edismax qf=text}iphone"
> parsedquery_toString: +(({_}text{_}:{_}query{_}) ({_}text{_}:"edismax qf text
> iphone"))
> Observed behavior:
> * {{_query_}} is not executed as a nested query
> * The expression is parsed as literal text tokens
> * No indication is returned that {{_query_}} was disallowed via {{uf}}
> Control case (allowing {{{}_query_{}}}):
> curl -iG "[http://localhost:8983/solr/repro/select]";
> --data-urlencode "defType=edismax"
> --data-urlencode "uf={_}query{_}"
> --data-urlencode 'q={_}query{_}:"\{!edismax qf=text}iphone"'
> --data-urlencode "debugQuery=true"
> Result:
> parsedquery_toString: +(+(text:iphone))
> Here {{_query_}} executes as a nested edismax subquery.
> Suggestion:
> Without changing existing behavior, it may be useful to provide an explicit
> signal when {{_query_}} is present but not allowed via {{uf}} (for example
> via debug output or logging). This could help detect configuration issues or
> query construction errors in programmatic clients.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
