[ https://issues.apache.org/jira/browse/LUCENE-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844467#action_12844467 ]
Robert Muir commented on LUCENE-2309: ------------------------------------- Hello, i commented yesterday but did not receive much feedback, so I want to elaborate some more: I suppose what I was trying to mention in my earlier comment here: https://issues.apache.org/jira/browse/LUCENE-2309?focusedCommentId=12844189&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12844189 is that while I really like the new TokenStream API, i would prefer it if we thought about making this flexible enough to support "different paradigms", including perhaps something that looks a lot like the old TokenStream API. The reason is, I notice a lot of existing code still under this old API, and I think that in some cases, perhaps its easier to work with, even if you aren't a new user. I definitely think for newer users the old API might have some advantages. I think its useful to consider supporting such an API, perhaps as an extension in contrib/analyzers, even if its not as fast or flexible as the new API, perhaps the tradeoff of speed and flexibility would be worth the ease for newer users. > Fully decouple IndexWriter from analyzers > ----------------------------------------- > > Key: LUCENE-2309 > URL: https://issues.apache.org/jira/browse/LUCENE-2309 > Project: Lucene - Java > Issue Type: Improvement > Components: Index > Reporter: Michael McCandless > > IndexWriter only needs an AttributeSource to do indexing. > Yet, today, it interacts with Field instances, holds a private > analyzers, invokes analyzer.reusableTokenStream, has to deal with a > wide variety (it's not analyzed; it is analyzed but it's a Reader, > String; it's pre-analyzed). > I'd like to have IW only interact with attr sources that already > arrived with the fields. This would be a powerful decoupling -- it > means others are free to make their own attr sources. > They need not even use any of Lucene's analysis impls; eg they can > integrate to other things like [OpenPipeline|http://www.openpipeline.org]. > Or make something completely custom. > LUCENE-2302 is already a big step towards this: it makes IW agnostic > about which attr is "the term", and only requires that it provide a > BytesRef (for flex). > Then I think LUCENE-2308 would get us most of the remaining way -- ie, if the > FieldType knows the analyzer to use, then we could simply create a > getAttrSource() method (say) on it and move all the logic IW has today > onto there. (We'd still need existing IW code for back-compat). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org