[
https://issues.apache.org/jira/browse/SOLR-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133220#comment-18133220
]
Chris M. Hostetter edited comment on SOLR-8160 at 10/27/26, 8:23 PM:
---------------------------------------------------------------------
{quote}I'd like to see this feature implemented on the existing "terms" QParser
with a localparam named maybe "analyze" (boolean) {*}_and have it default to
true_{*}. As people already know about "terms", it seems to me a reasonable
choice.
{quote}
I don't have a strong opinion on a new {{fields}} parser vs a new
{{analyze=true|false}} option on the {{terms}} parser (other then: *IF* we go
the for an {{analyze}} local param on {{{}terms{}}}, then for parity it might
make sense to do the same for {{{}term{}}}?)
I *DO* have a strong opinion *AGAINST* adding this "local-param toggled for
analysis, {*}and a default of true{*}" ... adding {{analyze=true}} as a default
to the existing {{terms}} parser would not only break backcompat, but that
backcompat break would be to the most common usage of (and original intention
behind the creation of) the {{terms}} parser: Passing back a list of
(post-analysis) facet terms for use in (multi-select) facet drill down
was (Author: hossman):
{quote}I'd like to see this feature implemented on the existing "terms" QParser
with a localparam named maybe "analyze" (boolean) {*}_and have it default to
true_{*}. As people already know about "terms", it seems to me a reasonable
choice.
{quote}
I don't have a strong opinion on a new {{fields}} parser vs a new {{analyze}}
option on the {{terms}} parser (other then: *IF* we go the for an {{analyze}}
local param on {{{}terms{}}}, then for parity it might make sense to do the
same for {{{}term{}}}?)
I *DO* have a strong opinion *AGAINST* adding this "local-param toggled for
analysis, {*}and a default of true{*}" ... adding {{analyze=true}} as a default
to the existing {{terms}} parser would not only break backcompat, but that
backcompat break would be to the most common usage of (and original intention
behind the creation of) the {{terms}} parser: Passing back a list of
(post-analysis) facet terms for use in (multi-select) facet drill down
> Terms query parser should optionally do query analysis
> -------------------------------------------------------
>
> Key: SOLR-8160
> URL: https://issues.apache.org/jira/browse/SOLR-8160
> Project: Solr
> Issue Type: Improvement
> Components: query parsers, search
> Affects Versions: 5.3
> Reporter: Devansh Dhutia
> Assignee: David Smiley
> Priority: Major
>
> Field setup as
> {code}
> <field name="cs" type="string_ci" indexed="true" stored="true"
> multiValued="false" required="false" />
> <fieldType name="string_ci" class="solr.TextField" sortMissingLast="true">
> <analyzer type="index">
> <tokenizer class="solr.KeywordTokenizerFactory" />
> <filter class="solr.LowerCaseFilterFactory" />
> </analyzer>
> <analyzer type="query">
> <tokenizer class="solr.KeywordTokenizerFactory" />
> <filter class="solr.LowerCaseFilterFactory" />
> </analyzer>
> </fieldType>
> {code}
> Value sent to cs field for indexing include: AA, BB
> Following is observed
> {code}&fq={!terms f=cs}AA,BB{code} yields 0 results
> {code}&fq={!terms f=cs}aa,bb{code} yields 2 results
> {code}&fq=cs:(AA BB){code} yields 2 results
> {code}&fq=cs:(aa bb){code} yields 2 results
> The first variant above should behave like the other 3 & obey query time
> analysis
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
