[
https://issues.apache.org/jira/browse/SOLR-17715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18032678#comment-18032678
]
Rahul Goswami edited comment on SOLR-17715 at 10/24/25 6:34 AM:
----------------------------------------------------------------
[~dsmiley] If a user creates a SolrRequest and calls
SolrRequest.process(SolrClient,collection) we can mandate them to use
request.setPath(String). However there are a bunch of
SolrClient.query(SolrParams) utility methods where there is no handle to
indicate the request handler other than setting the "qt" parameter on
SolrParams (eg: with SolrQuery object).
If we reeeally want to get rid of the "qt" param, we need to handle this case
with SolrClient. My WIP implementation would achieve this as follows:
1) Have setRequestHandler and getRequestHandler methods moved from SolrQuery to
SolrParams (base class). --> This allows users using
SolrClient.query(collection,params) to indicate the handler. This would also
mean these methods will no longer be marked deprecated.
2) In SolrQuery.setParam(String,String) and ModifiableSolrParams.set(String,
String) throw an exception if user tries to set "qt". This would be under a
"solr.solrj.qt.enabled" flag that defaults to false. Set this flag to true in
tests to allow them to pass in the interim.
3) Make changes outside of the tests to adhere to the same pattern of setting
the handler so that things work fine in the user environment (running with
"solr.solrj.qt.enabled" false)
Wanted to check if this sounds like the right direction before I go too far
into the implementation, since there are still a bunch of references to "qt"
outside of the tests (although tests make the bulk of it) that will need to be
reworked (?)
was (Author: [email protected]):
[~dsmiley] If a user creates a SolrRequest and calls
SolrRequest.process(SolrClient,collection) we can mandate them to use
request.setPath(String). However there are a bunch of
SolrClient.query(SolrParams) utility methods where there is no handle to
indicate the request handler other than setting the "qt" parameter on
SolrParams (eg: with SolrQuery object).
If we reeeally want to get rid of the "qt" param, we need to handle this case
with SolrClient. My WIP implementation would achieve this as follows:
1) Have setRequestHandler and getRequestHandler methods moved from SolrQuery to
SolrParams (base class). --> This allows users using
SolrClient.query(collection,params) to indicate the handler. This would also
mean these methods will no longer be marked deprecated.
2) In SolrQuery.setParam(String,String) and ModifiableSolrParams.set(String,
String) throw an exception if user tries to set "qt". This would be under a
"solr.solrj.qt.enabled" flag that defaults to false. Set this flag to true in
tests to allow them to pass in the interim.
3) Make changes outside of the tests to adhere to the same pattern of setting
the handler so that things work fine in the user environment (running with
"solr.solrj.qt.enabled" false)
Wanted to check if this sounds like the right direction before I go too far
into the implementation since there are still a bunch of references to "qt"
outside of the tests (although tests make the bulk of it) that will need to be
reworked (?)
> Remove "qt" param path support in SolrJ
> ---------------------------------------
>
> Key: SOLR-17715
> URL: https://issues.apache.org/jira/browse/SOLR-17715
> Project: Solr
> Issue Type: Task
> Components: SolrJ
> Reporter: David Smiley
> Priority: Blocker
> Labels: newdev, pull-request-available
> Fix For: 10.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> SolrJ doesn't need the "qt" param; SolrJ can create requests with whatever
> the desired path should be as a parameter to the SolrRequest constructor.
> The "qt" param complicates interpreting a request to know where to send it.
> And it still shows up on the request, which the Solr backend hasn't handled
> for a long time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
