lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3017) Allow edismax stopword filter factory implementation to be specified
Date Sun, 29 Jan 2012 18:03:10 GMT

    [ https://issues.apache.org/jira/browse/SOLR-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195810#comment-13195810
] 

Erick Erickson commented on SOLR-3017:
--------------------------------------

A couple of questions:
1> I notice that guava is in here. The only other place I see imports for google.common
is in the carrot code. Does anyone object to guava getting used in core? I only ask because
it's used in so few places, do we prefer apache commons StringUtils for this kind of stuff
or do we just not care?

2> In ExtendedDismaxQParserPlugin, around lines 1140 (in noStopwordFilterAnalyzer) there
are a couple of tests like:
      if (stopwordFilterFactoryClass.isInstance(tf)) {
  
Scanning the code, it seems like stopwordFilterFactoryClass could be null, an NPE here seems
questionable.

Otherwise, this seems fine to me from a tactical perspective, anyone want to weigh in on whether
this is a good thing overall?
                
> Allow edismax stopword filter factory implementation to be specified
> --------------------------------------------------------------------
>
>                 Key: SOLR-3017
>                 URL: https://issues.apache.org/jira/browse/SOLR-3017
>             Project: Solr
>          Issue Type: Improvement
>    Affects Versions: 4.0
>            Reporter: Michael Dodsworth
>            Priority: Minor
>             Fix For: 4.0
>
>         Attachments: SOLR-3017.patch, edismax_stop_filter_factory.patch
>
>
> Currently, the edismax query parser assumes that stopword filtering is being done by
StopFilter: the removal of the stop filter is performed by looking for an instance of 'StopFilterFactory'
(hard-coded) within the associated field's analysis chain.
> We'd like to be able to use our own stop filters whilst keeping the edismax stopword
removal goodness. The supplied patch allows the stopword filter factory class to be supplied
as a param, "stopwordFilterClassName". If no value is given, the default (StopFilterFactory)
is used.
> Another option I looked into was to extend StopFilterFactory to create our own filter.
Unfortunately, StopFilterFactory's 'create' method returns StopFilter, not TokenStream. StopFilter
is also final.

--
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message