lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] Updated: (LUCENE-2374) Add reflection API to AttributeSource/AttributeImpl
Date Wed, 19 Jan 2011 16:28:45 GMT


Uwe Schindler updated LUCENE-2374:

    Attachment: LUCENE-2374.patch

First preview of trunk patch:
- Removed useless equals() and hashCode() from internal attributes
- Removed backwards layer from previous patch / contrib-qp needs no special handling anymore
- Removed deprecated AnalysisRequestHandler instead of fixing it - still test need to be cleaned
- (Field|Document)AnalysisRequestHandler now works primarily on BytesRef, especially for highlighting
- Using BytesRef to wrap Payloads to easy print them as hex using BytesRef.toString()
- There is still one analysis test failing: as NumericTermAttribute does not support cloning,
analysis does not work and test fails. I will now open another issue to fix this (make NumericTermAttribute

> Add reflection API to AttributeSource/AttributeImpl
> ---------------------------------------------------
>                 Key: LUCENE-2374
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: contrib/analyzers
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 3.1, 4.0
>         Attachments: LUCENE-2374-3x.patch, LUCENE-2374-3x.patch, LUCENE-2374-3x.patch,
LUCENE-2374-3x.patch, LUCENE-2374-3x.patch, LUCENE-2374-3x.patch, LUCENE-2374.patch, shot1.png,
shot2.png, shot3.png, shot4.png
> AttributeSource/TokenStream inspection in Solr needs to have some insight into the contents
of AttributeImpls. As LUCENE-2302 has some problems with toString() [which is not structured
and conflicts with CharSequence's definition for CharTermAttribute], I propose an simple API
that get a default implementation in AttributeImpl (just like toString() current):
> - Iterator<Map.Entry<String,?>> AttributeImpl.contentsIterator() returns
an iterator (for most attributes its a singleton) of a key-value pair, e.g. "term"->"foobar","startOffset"->Integer.valueOf(0),...
> - AttributeSource gets the same method, it just concat the iterators of each getAttributeImplsIterator()
> No backwards problems occur, as the default toString() method will work like before (it
just gets iterator and lists), but we simply remove the documentation for the format. (Char)TermAttribute
gets a special impl fo toString() according to CharSequence and a corresponding iterator.
> I also want to remove the abstract hashCode() and equals() methods from AttributeImpl,
as they are not needed and just create work for the implementor.

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