lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] Commented: (LUCENE-2314) Add AttributeSource.copyTo(AttributeSource)
Date Sat, 13 Mar 2010 13:35:27 GMT


Uwe Schindler commented on LUCENE-2314:

bq. Minor comment - in copyTo, can you put state.attribute.getClass() in the message of the
thrown exception, so whoever encounters it will know what's the invalid attribute?

Good idea, the same should be done for restoreState (the code way copied from there).

bq. On a more general note, can State implement Iterable?

It could, but as State is itsself a linked list element it would be... strange. But of course
we could make it Iterable<AttributeImpl>. But the internal implementations of AttributeSource
should not use this interface as it is optimized for speed, so the creation of iterators is
a no-go here.

> Add AttributeSource.copyTo(AttributeSource)
> -------------------------------------------
>                 Key: LUCENE-2314
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>            Priority: Minor
>             Fix For: 3.1
>         Attachments: LUCENE-2314.patch
> One problem with AttributeSource at the moment is the missing "insight" into AttributeSource.State.
If you want to create TokenStreams that inspect cpatured states, you have no chance. Making
the contents of State public is a bad idea, as it does not help for inspecting (its a linked
list, so you have to iterate).
> AttributeSource currently contains a cloneAttributes() call, which returns a new AttrubuteSource
with all current attributes cloned. This is the (more expensive) captureState. The problem
is that you cannot copy back the cloned AS (which is the restoreState). To use this behaviour
(by the way, ShingleMatrix can use it), one can alternatively use cloneAttributes and copyTo.
You can easily change the cloned attributes and store them in lists and copy them back. The
only problem is lower performance of these calls (as State is a very optimized class).
> One use case could be:
> {code}
> AttributeSource state = cloneAttributes();
> // .... do something ...
> state.getAttribute(TermAttribute.class).setTermBuffer(foobar);
> // ... more work
> state.copyTo(this);
> {code}

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