[
https://issues.apache.org/jira/browse/JENA-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15227986#comment-15227986
]
ASF subversion and git services commented on JENA-1134:
-------------------------------------------------------
Commit 0bc25005a35d72f5053be0aa1602e40e09fb9bf3 in jena's branch
refs/heads/master from [~osma]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=0bc2500 ]
JENA-1134: basic support for AnalyzingQueryParser
> Support alternative QueryParsers in jena-text
> ---------------------------------------------
>
> Key: JENA-1134
> URL: https://issues.apache.org/jira/browse/JENA-1134
> Project: Apache Jena
> Issue Type: Improvement
> Components: Text
> Affects Versions: Jena 3.0.1
> Reporter: Osma Suominen
> Assignee: Osma Suominen
>
> Jena-text is currently hardwired to use Lucene QueryParser. This parser is
> (intentionally) limited so that it doesn't analyze wildcard queries. Instead
> they will be expanded directly.
> This is a problem if you want to do accent-insensitive wildcard queries
> (using ASCIIFoldingFilter) or other wildcard queries which rely on a special
> analyzer. However, Lucene offers an alternate parser, AnalyzingQueryParser,
> that could be used in such cases.
> I'd like to extend jena-text with a configuration parameter that allows using
> AnalyzingQueryParser instead of the standard QueryParser. For example, the
> configuration could look like this:
> {noformat}
> <#indexLucene> a text:TextIndexLucene ;
> text:directory <file:Lucene> ;
> text:queryParser text:AnalyzingQueryParser ;
> text:queryAnalyzer [
> a text:ConfigurableAnalyzer ;
> text:tokenizer text:KeywordTokenizer ;
> text:filters (text:ASCIIFoldingFilter text:LowerCaseFilter)
> ]
> text:entityMap <#entMap> ;
> {noformat}
> I've written some very preliminary code to implement this, but I'm not yet
> satisfied with it. It's a bit problematic because the parser cannot be
> constructed in advance but must be dynamically created separately for each
> query (because it needs parameters that can differ between queries).
> Thus the TextIndexConfig must store information about which parser variant to
> use, but not the actual QueryParser/AnalyzingQueryParser instance. This isn't
> rocket science though, maybe some kind of Factory pattern would work.
> For some background for why this is needed, see this Skosmos issue:
> https://github.com/NatLibFi/Skosmos/issues/424
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
