ispringer commented on code in PR #4652: URL: https://github.com/apache/solr/pull/4652#discussion_r4260040928
########## solr/core/src/java/org/apache/solr/search/DisMaxQParser.java: ########## Review Comment: You're right on (2), I misread your suggestion, sorry about that. On (1), the piece I failed to spell out is `autoGeneratePhraseQueries`. The "`wi-fi` already becomes `"wi fi"`" behavior only happens when the qf field type has it set to true. It has defaulted to false since schema 1.4 (`TextField`), and in the `_default` configset only `text_en_splitting*` enable it; `text_general` and `text_cjk` don't. With it false, the qf clause for `wi-fi` is `(wi fi)`, a plain disjunction, so the pf boost is the only adjacency signal, and gating on clause count would drop it. CJK with `CJKBigram` is the worst case: every query is a single clause, so clause-count gating would disable pf for essentially all CJK queries. Checking the analyzed pf phrase also keeps DisMax consistent with eDisMax, whose `minClauseSize` gate counts analyzed terms in the pf phrase rather than clauses, so eDisMax keeps pf for `wi-fi` too. I did take your structural suggestion: the check now lives in `addMainQuery`, and `getPhraseQuery` is unchanged from `main` (6590729e2b). I also added a DisMax test case on a field with `autoGeneratePhraseQueries="false"` showing `wi-fi` keeps its pf boost, and confirmed it fails if the gate is switched to clause count. The existing `wi-fi`/`usa` assertions were also matching the qf clause (the test schema is version 1.0, so the flag defaults to true there), so I tightened them to match the pf clause specifically. (Analysis and changes co-authored with Claude Code, Opus 5.5.) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
