[
https://issues.apache.org/jira/browse/SOLR-10310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15940483#comment-15940483
]
Steve Rowe edited comment on SOLR-10310 at 3/24/17 2:52 PM:
------------------------------------------------------------
bq. I'd like to understand your point of view here better; I'm sure you have
some insight. "sow" is a query parameter.... in my view, why then wouldn't an
auto-phrase-whatever also be?
Because {{autoGeneratePhraseQueries}} is not now a query param, and the goal is
to preserve its current behavior when {{sow=false}}.
[~dsmiley] pointed out on #solr-dev IRC:
bq. [I]n Solr, query parameters *can* be per field
bq. f.myfield.autoGeneratePhraseQueries
Which directly (and correctly) contradicts my assertion ("another step back")
that moving the configuration location from schema to request param would
disallow per-field configuration. And I agree, {{autoGeneratePhraseQueries}}
could be converted into a (optionally per-field) request param, but the current
implementation is not like that, and SOLR-10357 is about fixing the current
incompatibility of {{autoGeneratePhraseQueries="true"}} with {{sow=false}}, so
I'd rather keep the focus where the biggest problem is, and defer the request
param vs. schema discussion for later.
was (Author: steve_rowe):
bq. I'd like to understand your point of view here better; I'm sure you have
some insight. "sow" is a query parameter.... in my view, why then wouldn't an
auto-phrase-whatever also be?
Because {{autoGeneratePhraseQueries}} is not now a query param, and the goal is
to preserve its current behavior when {{sow=false}}.
[~dsmiley] pointed out on #solr-dev IRC:
bq. [I]n Solr, query parameters *can* be per field
bq. f.myfield.autoGeneratePhraseQueries
Which directly (and correctly) contradicts my assertion ("another step back")
that moving the configuration location from schema to request param would
disallow per-field configuration. And I agree, {{autoGeneratePhraseQueries}}
could be converted into a (optionally per-field) phrase param, but the current
implementation is not like that, and SOLR-10357 is about fixing the current
incompatibility of {{autoGeneratePhraseQueries="true"}} with {{sow=false}}, so
I'd rather keep the focus where the biggest problem is, and defer the request
param vs. schema discussion for later.
> By default, stop splitting on whitespace prior to analysis in edismax and
> "Lucene"/standard query parsers
> ---------------------------------------------------------------------------------------------------------
>
> Key: SOLR-10310
> URL: https://issues.apache.org/jira/browse/SOLR-10310
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Steve Rowe
>
> SOLR-9185 introduced an option on the edismax and standard query parsers to
> not perform pre-analysis whitespace splitting: the {{sow=false}} request
> param.
> On master/7.0, we should make {{sow=false}} the default.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
