lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1794) implement reusableTokenStream for all contrib analyzers
Date Sun, 16 Aug 2009 06:18:15 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743816#action_12743816
] 

Shai Erera commented on LUCENE-1794:
------------------------------------

bq. right now consumers like lucene indexing call reset() on the stream, but I see the prototype
ReusingAnalyzer also calling reset() on the stream.

I don't think that's a new problem - I simply coded what I think most Analyzers that do impl
reusableTS do. And if there are reusableTS impls that don't call reset() on purpose, then
we shouldn't call it.

Therefore, I think that we should change our code to not call reset(). I don't think there's
a reusableTS impl which does not call reset(), because it relies on the consumer to do it
(nobody guarantees that anyway). We should simply note that on reusableTS javadoc (e.g., something
like "return an already reset token stream"). I don't mind doing that in a separate issue
if that's what you prefer.

> implement reusableTokenStream for all contrib analyzers
> -------------------------------------------------------
>
>                 Key: LUCENE-1794
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1794
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: contrib/analyzers
>            Reporter: Robert Muir
>            Assignee: Robert Muir
>            Priority: Minor
>             Fix For: 2.9
>
>         Attachments: LUCENE-1794-reusing-analyzer.patch, LUCENE-1794.patch, LUCENE-1794.patch,
LUCENE-1794.patch, LUCENE-1794.patch, LUCENE-1794.patch, LUCENE-1794.patch
>
>
> most contrib analyzers do not have an impl for reusableTokenStream
> regardless of how expensive the back compat reflection is for indexing speed, I think
we should do this to mitigate any performance costs. hey, overall it might even be an improvement!
> the back compat code for non-final analyzers is already in place so this is easy money
in my opinion.

-- 
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message