apache
Refactor: QueryResult: don't provide to SolrIndexSearcher
IMO it's wrong for SolrIndexSearcher.search(QueryCommand) to also take a QueryResult param and not return it. It's an "out" parameter, but there is no need for this! This PR deprecates that method and replaces it with one that does the right thing. In one spot, I see QueryResult early segment termination being set up in QueryComponent but that should be done in SolrIndexSearcher.
I also deprecated many low-value SolrIndexSearcher methods involving QueryCommand; a QueryCommand is a superior API to methods taking lots of parameters. Some weren't even called. Some were in a place or two. I inlined some of those albeit not all. Some were called by SolrPluginUtils methods that themselves felt like questionable utility methods so I deprecated them too; they are used by DebugComponent and MLTHandler but IMO if they need to exist, DebugComponent would be the best home as it's the principal place for debut output to be.
(no CHANGES.txt; just deprecating low level stuff & refactoring stuff that shouldn't have an effect)
WDYT @cpoerschke
(no CHANGES.txt; just deprecating low level stuff & refactoring stuff that shouldn't have an effect)
WDYT @cpoerschke
Perhaps QueryComponent and SolrIndexSearcher might not be totally low level stuff here, i.e. folks with custom components (or just a copy/paste/adapt 'fork' of QueryComponent) might call the APIs being deprecated.
Therefore it could be nice to "Other Changes" mention about the deprecation before it goes away in Solr 10 or so. The @deprecated annotation serves the same purpose but only slightly so i.e. they might only get noticed when users try to upgrade whereas a mention in the CHANGES.txt might trigger an earlier realisation of "hey, we need to do some prep work or keep this in mind when upgrading our custom query component in future" etc.
Therefore it could be nice to "Other Changes" mention about the deprecation before it goes away in Solr 10 or so. The @deprecated annotation serves the same purpose but only slightly so i.e. they might only get noticed when users try to upgrade whereas a mention in the CHANGES.txt might trigger an earlier realisation of "hey, we need to do some prep work or keep this in mind when upgrading our custom query component in future" etc.
I think deprecation is enough of an aid to users along with git commit message too so users see the explanation. IMO the value to effort ratio small things to CHANGES.txt is low. But since you ask for it, I'll do so.
Planned Git commit message:
QueryResult refactoring so that it's only returned from SolrIndexSearcher instead of being provided to it. Deprecated APIs in 9x; should be removed later. Deprecated old methods in SolrIndexSearcher that are less clear than using QueryCommand. Deprecated related old methods in QueryPluginUtils; some should move to DebugComponent