[
https://issues.apache.org/jira/browse/SOLR-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13425932#comment-13425932
]
Michael Dodsworth commented on SOLR-3580:
-----------------------------------------
Thanks for the feedback, Jack/Yonik.
1 - support for mixed-case operators is as before: they are interpreted as
operators. Having said that, there appears to be an subtle bug with the 'mm'
toggling behaviour. The operator counting (used to determine whether 'mm' needs
to be disabled) only accepts strict uppercase and lowercase, whereas the query
rebuild accepts mixed-case. I can also fix that up and add a test.
2 - the 'supportedLowercaseOperators' parameter would be in addition to
'lowercaseOperators', rather than replacing it. If 'lowercaseOperators' is
true, we look for a 'supportedLowercaseOperators' value. If no value is
provided, we use the default (and, or), which means we have backwards
compatibility.
Yonik - yeah, Jan's proposal is absolutely the most flexible. I guess my
concerns were:
- that it might snowball into wanting to have an external, stopword-esk file
for per-language operator support (minor concern)
- that we'd lose some backwards compatibility, as currently mixed-case
operators are supported (although the default set could be expanded to
accommodate this, if needed)
- the interaction between the 'lowercaseOperators' parameter and 'valid*'
might get a little funky. For example, if we simply ignore 'lowercaseOperators'
when a 'valid*' parameter is present, there is no potential for confusion BUT
toggling lowercase operator support per query then becomes a head-ache (as the
upstream client needs to pass through the supported uppercase operators). If we
allow interaction between 'lowercaseOperators' and 'valid*', which parameter
takes priority? To allow toggling per-query, lowercaseOperators *should* take
priority. Perhaps a good dollop of documentation would be enough here
Let me extend the patch to switch-over to Jan's proposal so people can take a
look.
Cheers,
> In ExtendedDismax, lowercase 'not' operator is not being treated as an
> operator when 'lowercaseOperators' is enabled
> --------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-3580
> URL: https://issues.apache.org/jira/browse/SOLR-3580
> Project: Solr
> Issue Type: Bug
> Components: query parsers
> Affects Versions: 4.0-ALPHA
> Reporter: Michael Dodsworth
> Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-3580-proposal.patch, SOLR-3580.patch
>
>
> When lowercase operator support is enabled (for edismax), the lowercase 'not'
> operator is being wrongly treated as a literal term (and not as an operator).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
