[
https://issues.apache.org/jira/browse/BLUR-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13574203#comment-13574203
]
Aaron McCurry commented on BLUR-49:
-----------------------------------
So with point 2, at the end of the constructing a the bluranalyzer for each
table (there should be only one for each table) it should be ready to go and
not require any further changes. So currently we do this by passing in the
analyzer definition (thrift analyzer struct) Into the constructor. There may be
multiple fields with their own initFunctions each one producing (potentially)
different analyzers. So my thought was that while it was constructing the
normal analyzer by class name, that the initFunction would logically go with
that block of code because it is an alternative way to create a user defined
analyzer. Let me know if doesn't make sense, I may be confused. :)
Aaron
> BlurAnalyzer add constructor arguments
> --------------------------------------
>
> Key: BLUR-49
> URL: https://issues.apache.org/jira/browse/BLUR-49
> Project: Apache Blur
> Issue Type: Bug
> Affects Versions: 0.2.0
> Reporter: Aaron McCurry
> Fix For: 0.2.0
>
> Attachments:
> 0001-BLUR-ID-49-Added-Javascript-method-call-to-intialize.patch,
> 0001-BLUR-ID-49-Blur-Analyzer-Added-constructor-arguments.patch
>
>
> In the 0.2-dev branch, the BlurAnalyzer should be enhanced to allow
> constructor arguments to be passed in the ClassDefinition.arguments map. Not
> sure what the best way to implement this, but the use case would be creating
> a StandardAnalyzer with a non-default set of stop words.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
