Skip to content

SOLR-18371: remove the deprecated pre-QueryCommand SolrIndexSearcher methods - #4754

Open
serhiy-bzhezytskyy wants to merge 1 commit into
apache:mainfrom
serhiy-bzhezytskyy:SOLR-18371-remove-pre-querycommand-methods
Open

SOLR-18371: remove the deprecated pre-QueryCommand SolrIndexSearcher methods#4754
serhiy-bzhezytskyy wants to merge 1 commit into
apache:mainfrom
serhiy-bzhezytskyy:SOLR-18371-remove-pre-querycommand-methods

Conversation

@serhiy-bzhezytskyy

@serhiy-bzhezytskyy serhiy-bzhezytskyy commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

https://issues.apache.org/jira/browse/SOLR-18371

Removes all 9 deprecated SolrIndexSearcher members the ticket names — search(QueryResult, QueryCommand) plus 8 getDocList/getDocListAndSet overloads — and the 3 already-commented-out doc(...) blocks with their stale javadoc. @Deprecated count 12 → 0, verified by listing each exact signature against origin/main, not by counting. One correction to the ticket text: none of the 9 carry an explicit @deprecated Use X instead javadoc sentence — the replacement is visible only in each method's own body, not its documentation.

5 in-tree call sites migrated (4 in MoreLikeThisHandler, 1 in HighlighterTest) — the only ones in the whole tree; a naive grep returns ~100 hits, almost all surviving overloads or unrelated classes. 84 tests, 0 failures.

On the ticket's own caution about third-party usage: no @lucene.experimental/internal markers, no ref-guide/upgrade-notes mentions either way. The deprecation shipped in 10.0.0 (#2524, 2024-07-03), so it's had a real release's exposure.

Two small cleanups made possible by the removal: search(QueryCommand)'s body is now the two lines the deprecated overload contained, and getDocListC builds its own QueryResult instead of taking one as an always-fresh, discarded-by-callers out-parameter — resolving the // TODO don't take QueryResult as arg comment that sat on it.

AI-assisted (Claude Sonnet 5)

…methods

Nine live deprecated members go: search(QueryResult, QueryCommand), three
getDocList overloads and five getDocListAndSet overloads, plus three
doc(...) overloads that were already commented out with stale javadoc.
@deprecated count 12 -> 0, verified by listing each exact signature against
origin/main, not by counting.

Only five call sites in the whole tree: four in MoreLikeThisHandler, one in
HighlighterTest. A naive grep for getDocList/getDocListAndSet returns ~100
hits, almost all of them the surviving overloads or unrelated classes.

Two small cleanups the removal made possible: search(QueryCommand)'s body
is now the two lines the deprecated overload contained, and getDocListC
builds its own QueryResult instead of taking one as an always-fresh,
discarded-by-callers out-parameter - resolving its own
"TODO don't take QueryResult as arg" comment.

Verified: compileJava/compileTestJava, ecjLintMain/Test, spotlessJavaCheck,
renderJavadoc, and MoreLikeThisHandlerTest, MoreLikeThisComponentTest,
HighlighterTest, TestSolrQueryParser, TestDistributedSearch - 84 tests,
0 failures.

AI-assisted (Claude Sonnet 5)
results.docList = searcher.getDocList(boostedMLTQuery, filters, null, start, rows, flags);
}
return results;
// setNeedDocSet must follow setFlags: it sets or clears GET_DOCSET within the flags

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugh... wow, that sounds like a "foot gun"... is there anyway to prevent someone from making this mistake? Or, is it so localized to just this class that no one else will accidetnally do setNeedDocSet before setFlags?

Any ideas?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

setFlags ORs bits in; setNeedDocSet OR's/AND-NOTs the GET_DOCSET bit in that same field. Order only matters for the false case — clearing, then a later setFlags whose value includes that bit, would undo the clear. Here flags only ever carries GET_SCORES, so it can't actually collide.

.setFlags(flags);
QueryResult qr = new QueryResult();
newSearcher.getDocListC(qr, qc);
// called for its cache side effect; the returned QueryResult is unused

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the comment.

.setQuery(query)
.setOffset(0)
.setLen(1)
.setNeedDocSet(true)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should there have been setFlags first??

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No — there's no setFlags(...) call in this chain at all, so there's nothing for setNeedDocSet(true) to conflict with. It just OR's GET_DOCSET onto the default (0) flags.

@epugh epugh left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SOme questions.. love how much code this one removes!

@serhiy-bzhezytskyy

Copy link
Copy Markdown
Contributor Author

cc @dsmiley -- this removes search(QueryResult, QueryCommand), which you deprecated in 2024. Straightforward once the replacement (search(QueryCommand)) fully absorbed it; flagging since it's yours.

AI-assisted (Claude Sonnet 5)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants