lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] [Commented] (LUCENE-2309) Fully decouple IndexWriter from analyzers
Date Sun, 17 Jul 2011 14:42:59 GMT


Robert Muir commented on LUCENE-2309:

Yes, so my idea is basically that Analyzer gets ReusableAnalyzerBase's API completely, so
its reusableTokenStream() is final.

In order for this to work, we need to first fix the limitation of ReusableAnalyzerBase:
 * ReusableAnalyzerBase is a simplification of Analyzer that supports easy reuse
 * for the most common use-cases. Analyzers such as
 * {@link PerFieldAnalyzerWrapper} that behave differently depending upon the
 * field name need to subclass Analyzer directly instead.

this looks easy to do, the current implementation always puts a TokenStreamComponents into
the 'previousTokenStream'. Instead, reusableAnalyzerBase can have an optional ctor with something
like ReuseStrategy, of which there are two:

* GLOBAL: this is what it does now, reuse across all fields, and should be the default
* PERFIELD: this one instead puts a Map<String,TokenStreamComponents> into the previous
tokenstream and reuses on a per-field basis.

then the problem is solved, and we could name this thing Analyzer, make all analyzers extend
it directly, remove the non-reusable TokenStream(), it would only have a final reusableTokenStream()
for the consumers.

> Fully decouple IndexWriter from analyzers
> -----------------------------------------
>                 Key: LUCENE-2309
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: core/index
>            Reporter: Michael McCandless
>              Labels: gsoc2011, lucene-gsoc-11, mentor
>             Fix For: 4.0
>         Attachments: LUCENE-2309.patch
> 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|].
> 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.
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message