[
https://issues.apache.org/jira/browse/SOLR-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465107#comment-16465107
]
Munendra S N edited comment on SOLR-12303 at 5/6/18 12:49 PM:
--------------------------------------------------------------
[~mkhludnev]
Reason for using *request.getPath()* instead of *qt* is that in case of HTTP
Requests, there would be cases where *qt* won't be set.
For client library(SolrJ) and test cases *qt* needs to be set to use a
different handler. For HTTP Requests, it is not required.
So, In case of HTTP request subquery won't inherit path(as qt need not be
specified).
Hence, *request.getPath()* needs to be used.
In case of the client libraries, *qt* and *getPath()* would be same. In case of
HTTP request, it could be different.
Also, whenever *qt* is specified it is used but behavior mentioned in the
documentation for HTTP request is different.
*qt* is used for HTTP request if */select* is path and there is no handler
with */select*
[https://wiki.apache.org/solr/CoreQueryParameters]
[https://wiki.apache.org/solr/SolrRequestHandler#Old_handleSelect.3Dtrue_Resolution_.28qt_param.29]
https://lucene.apache.org/solr/guide/7_0/major-changes-in-solr-7.html#changes-to-default-behaviors
- handleSelect change
The path using *request.getPath()*, doesn't handle a case,
* When */select* is not available and handleSelect=true. it should use *qt* (I
can work on adding this functionality)
was (Author: munendrasn):
[~mkhludnev]
Reason for using *request.getPath()* instead of *qt* is that in case of HTTP
Requests, there would be cases where *qt* won't be set.
For client library(SolrJ) and test cases *qt* needs to be set to use a
different handler. For HTTP Requests, it is not required.
So, In case of HTTP request subquery won't inherit path(as qt need not be
specified).
Hence, *request.getPath()* needs to be used.
In case of the client libraries, *qt* and *getPath()* would be same. In case of
HTTP request, it could be different.
Also, whenever *qt* is specified it is used but behavior mentioned in the
documentation for HTTP request is different.
*qt* is used for HTTP request if */select* is path and there is no handler
with */select*
[https://wiki.apache.org/solr/CoreQueryParameters]
[https://wiki.apache.org/solr/SolrRequestHandler#Old_handleSelect.3Dtrue_Resolution_.28qt_param.29]
https://lucene.apache.org/solr/guide/7_2/requesthandlers-and-searchcomponents-in-solrconfig.html
- handleSelect change
The path using *request.getPath()*, doesn't handle a case,
* When */select* is not available and handleSelect=true. it should use *qt* (I
can work on adding this functionality)
> Subquery Doc transform doesn't inherit path from original request
> -----------------------------------------------------------------
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Munendra S N
> Assignee: Mikhail Khludnev
> Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch,
> SOLR-12303.patch, SOLR-12303.patch
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc&q.op=AND&wt=json&q={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})&facet=false&fl=uniqueId&fl=score&fl=_children_:[subquery]&fl=uniqueId&origQuery=false&qf=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3&spellcheck=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}&rows=1
> {code}
> For this request, even though the path is */search*, the subquery request
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should
> be an option to override this behavior. (option to override is already
> available by specifying *qt*)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
