[
https://issues.apache.org/jira/browse/SOLR-17715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18032957#comment-18032957
]
Rahul Goswami commented on SOLR-17715:
--------------------------------------
My implementation throws a run time error if you try to do a
SolrQuery.setParam("qt",handler) or a ModifiableSolrParams.set("qt", handler).
That's how I understood the next step for this JIRA since
SolrQuery.set/getRequestHandler and CommonParams.QT have already been
deprecated.
I would like to understand better _why_ we are doing this, other than the
ambiguity of handling it on the Solr backend, which as you already mentioned
gets ignored today anyway? I am starting to think maybe this JIRA should be
marked resolved and we just stop at the deprecation to push users away from the
use of QT\(?\} Especially since this is not causing any breakage.
Note that there is no alternative today to using "qt" for implementations using
SolrClient.query(collection, SolrParams) set of convenience methods (vs users
of SolrRequest.process(client) who can use SolrRequest.setPath())). So only way
to achieve complete removal of support for qt is by having a
SolrParams.setRequestHandler() implementation afaik. I am sensing that's not a
direction we want to go in either.
> 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]
