[
https://issues.apache.org/jira/browse/SOLR-18332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109573#comment-18109573
]
Jason Gerlowski commented on SOLR-18332:
----------------------------------------
Alright! We've made pretty significant progress here. All of the easy,
uncomplicated removals are done and we're down to the last few QT usages that
tie into user-facing functionality:
* {{SolrDispatchFilter}} - the "main" usage that primarily comes up when "qt"
is mentioned. "qt" query parameter is used to override "/select" and choose a
different RequestHandler/API.
* {{PingRequestHandler}} - nearly identical capabilities to SolrDispatchFilter.
* {{cloud(...)}} Streaming Expression - a "qt" named-param in the streaming
expression is used to ping a requestHandler. Almost always used to switch
between "/select" (while prototyping) and the much faster but more restrictive
"/export" (in production).
* {{subquery}} Document Transformer - for a pseudo-field "foo", uses
query-params like 'foo.q', 'foo.rows', etc. to specify the request to make for
each document matching the primary (or "parent") query.
These are all "user facing". But I think we can deprecate/remove most or all of
these without any real loss of user-capabilites. My recommendation, starting
with what I'd guess is the least controversial, would be:
* Remove the SolrDispatchFilter support for "qt" entirely. It's not used by
any of the other qt-based features. Users are no poorer for its loss as they
can just specify the requestHandler/API they want by using the correct path.
* Deprecate {{{}cloud(...){}}}'s path/qt parameter and in its place add a
boolean flag (maybe "flexible=true" or "useSelect=true" or "prototype=true",
idk) that lets users choose between {{/select}} and {{{}/export{}}}. This
retains the benefit that "qt" was meant to serve here, but without the security
concerns of allowing users to specify an arbitrary path.
* check whether {{PingRequestHandler}} serves a compelling use case today, and
deprecate/remove this feature altogether.
** Making this case in detail deserves its own thread/ticket, but
PingRequestHandler is redundant entirely in SolrCloud mode. And even in
standalone mode, it doesn't serve much purpose. Anyone looking for a core-level
healthcheck can make queries to cores directly, without the
proxying/request-tunneling done by PingRequestHandler
> Remove usages of deprecated 'qt' parameter and related SolrJ functionality
> --------------------------------------------------------------------------
>
> Key: SOLR-18332
> URL: https://issues.apache.org/jira/browse/SOLR-18332
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Affects Versions: main(11.0)
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 15h 10m
> Remaining Estimate: 0h
>
> SOLR-17715 deprecated SolrQuery's setRequestHandler/getRequestHandler methods
> in favor of a new QueryRequest ctor that takes an explicit requestHandler.
> SolrJ users no longer need to send 'qt' to select a handler.
> There's some debate over whether this deprecation will "stick" and whether
> we'll be able to eliminate all usages of qt, but in the meantime there are
> many usages of 'qt' (and related methods) that are inarguably unnecessary.
> This ticket tracks incrementally removing usages of the deprecated SolrJ
> convenience methods / 'qt'-as-handler-override pattern in the codebase, in
> cases where a path-based alternative exists.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
