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 Fri, 12 Mar 2010 15:07:27 GMT


Robert Muir commented on LUCENE-2309:

So with the current APIs we cannot get around the requirement to reuse the same Attribute
instances during the whole indexing without a major speed impact.

I agree. I guess I'll try to simplifiy my concern: maybe we don't necessarily 
need something that looks like the old TokenStream API, but I feel it would
be worth our time to think about supporting 'some alternative API' that makes
it easier to work with lots of context across different Tokens.

I personally do not mind how this is done with the capture/restore state API,
but I feel that its pretty unnatural for many developers, and in the future folks
might want to do more complex analysis (maybe even light pos-tagging, etc)
that requires said context, and we should plan for this.

I feel this wasn't such an issue with the old TokenStream API, but maybe there
is another way to address this potential problem.

> Fully decouple IndexWriter from analyzers
> -----------------------------------------
>                 Key: LUCENE-2309
>                 URL:
>             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|].
> 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:
For additional commands, e-mail:

View raw message