[
https://issues.apache.org/jira/browse/SOLR-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14384060#comment-14384060
]
Michael McCandless commented on SOLR-1387:
------------------------------------------
I'm concerned about the StringHelper.contains that was added for this issue:
* Its signature implies it operates on BytesRef, but under the hood it
secretly assumes the bytes are valid UTF-8 (only for the ignoreCase=true case)
* It also secretly assumes Locale.ENGLISH for downcasing but the incoming
UTF-8 bytes may not be English
* It has potentially poor performance compared to known algos e.g.
http://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_string_search_algorithm
Can we move this method out for now, e.g. not put it in the shared StringHelper
utility class?
> Add more search options for filtering field facets.
> ---------------------------------------------------
>
> Key: SOLR-1387
> URL: https://issues.apache.org/jira/browse/SOLR-1387
> Project: Solr
> Issue Type: New Feature
> Components: search
> Reporter: Anil Khadka
> Assignee: Alan Woodward
> Fix For: Trunk, 5.1
>
> Attachments: SOLR-1387.patch
>
>
> Currently for filtering the facets, we have to use prefix (which use
> String.startsWith() in java).
> We can add some parameters like
> * facet.iPrefix : this would act like case-insensitive search. (or --->
> facet.prefix=a&facet.caseinsense=on)
> * facet.regex : this is pure regular expression search (which obviously would
> be expensive if issued).
> Moreover, allowing multiple filtering for same field would be great like
> facet.prefix=a OR facet.prefix=A ... sth like this.
> All above concepts could be equally applicable to TermsComponent.
--
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
