[jira] [Commented] (SOLR-8160) Terms query parser should optionally do query analysis
[
https://issues.apache.org/jira/browse/SOLR-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14955055#comment-14955055
]
Erik Hatcher commented on SOLR-8160:
With this change, it effectively makes it a "fields" query parser, like
"term"/"field". I wonder if we should keep "terms" as-is, and add a "fields"
query parser? (though I can't imagine a scenario where I wouldn't want the
field type analysis to apply when using terms, though I'd also pretty much
always use a string field type)
> 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
>
> Field setup as
> {code}
> multiValued="false" required="false" />
>
>
>
>
>
>
>
>
>
>
> {code}
> Value sent to cs field for indexing include: AA, BB
> Following is observed
> {code}={!terms f=cs}AA,BB{code} yields 0 results
> {code}={!terms f=cs}aa,bb{code} yields 2 results
> {code}=cs:(AA BB){code} yields 2 results
> {code}=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
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8160) Terms query parser should optionally do query analysis
[
https://issues.apache.org/jira/browse/SOLR-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14955080#comment-14955080
]
Jack Krupansky commented on SOLR-8160:
--
The doc is a bit misleading, for both the Term and Terms query parsers:
bq. documents matching any of the specified values. This can be useful for
generating filter queries from the external human readable terms returned by
the faceting or terms components
It should be explicit that these are indexed, already analyzed term values, not
"external human readable terms" as the doc indicates.
> 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
>
> Field setup as
> {code}
> multiValued="false" required="false" />
>
>
>
>
>
>
>
>
>
>
> {code}
> Value sent to cs field for indexing include: AA, BB
> Following is observed
> {code}={!terms f=cs}AA,BB{code} yields 0 results
> {code}={!terms f=cs}aa,bb{code} yields 2 results
> {code}=cs:(AA BB){code} yields 2 results
> {code}=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
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8160) Terms query parser should optionally do query analysis
[
https://issues.apache.org/jira/browse/SOLR-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14955109#comment-14955109
]
Yonik Seeley commented on SOLR-8160:
It feels like some amount of transformations to go from readable to indexed
should generally applied.
This is already done for most field types: for example numerics work:
{code}
http://localhost:8983/solr/techproducts/query?q={!terms f=popularity}8,9,10
{code}
I remember we did something similar for things like prefix queries...
selectively applying what made sense (i.e. lowercasing made sense, but stemming
did not).
> 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
>
> Field setup as
> {code}
> multiValued="false" required="false" />
>
>
>
>
>
>
>
>
>
>
> {code}
> Value sent to cs field for indexing include: AA, BB
> Following is observed
> {code}={!terms f=cs}AA,BB{code} yields 0 results
> {code}={!terms f=cs}aa,bb{code} yields 2 results
> {code}=cs:(AA BB){code} yields 2 results
> {code}=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
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
