[jira] Updated: (LUCENE-1118) core analyzers should not produce tokens > N (100?) characters in length

["Michael McCandless (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LUCENE-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael McCandless updated LUCENE-1118:
---------------------------------------

    Attachment: LUCENE-1118.patch

I fixed only StandardAnalyzer to skip terms longer than 255 chars by
default (it turns out SimpleAnalyzer, WhitespaceAnalyzer, StopAnalyzer
already prune tokens at 255 chars).

You can change the max allowed token length by calling
StandardAnalyzer.setMaxTokenLength.

I didn't use LengthFilter, because 1) I wanted to avoid copying the
massive term only to then filter it (makes performance faster) and, 2)
I wanted to increment position increment for the next valid token
after a series of too-long tokens.

All tests pass.  I plan to commit in a day or two.


> core analyzers should not produce tokens > N (100?) characters in length
> ------------------------------------------------------------------------
>
>                 Key: LUCENE-1118
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1118
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>            Priority: Minor
>         Attachments: LUCENE-1118.patch
>
>
> Discussion that led to this:
>   http://www.gossamer-threads.com/lists/lucene/java-dev/56103
> I believe nearly any time a token > 100 characters in length is
> produced, it's a bug in the analysis that the user is not aware of.
> These long tokens cause all sorts of problems, downstream, so it's
> best to catch them early at the source.
> We can accomplish this by tacking on a LengthFilter onto the chains
> for StandardAnalyzer, SimpleAnalyzer, WhitespaceAnalyzer, etc.
> Should we do this in 2.3?  I realize this is technically a break in
> backwards compatibility, however, I think it must be incredibly rare
> that this break would in fact break something real in the application?

-- 
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