You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2026/07/14 13:03:00 UTC
[jira] [Commented] (SOLR-17715) SolrJ / QueryRequest - stop sending "qt" param
[ https://issues.apache.org/jira/browse/SOLR-17715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18096178#comment-18096178 ]
ASF subversion and git services commented on SOLR-17715:
--------------------------------------------------------
Commit 51557ecf3f97d4ded66146aedc22555c9844ee62 in solr's branch refs/heads/main from David Smiley
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=51557ecf3f9 ]
SOLR-17715: un-deprecate CommonParams.QT (#4461)
> SolrJ / QueryRequest - stop sending "qt" param
> ----------------------------------------------
>
> Key: SOLR-17715
> URL: https://issues.apache.org/jira/browse/SOLR-17715
> Project: Solr
> Issue Type: Task
> Components: SolrJ
> Reporter: David Smiley
> Priority: Major
> Labels: newdev, pull-request-available
> Fix For: 10.1, 9.11
>
> Time Spent: 5h
> 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.
> ----
> Originally this issue was basically "deprecate qt" but now it's morphed to be a QueryRequest improvement with additional constructors so callers can be explicit about the path without resorting to "qt", and also includes some "qt" filtering here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org