Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## org.apache.lucene.collation
Class CollationKeyAnalyzer

    java.lang.Object
      org.apache.lucene.analysis.Analyzer
          org.apache.lucene.collation.CollationKeyAnalyzer

All Implemented Interfaces:
  Closeable

    public final class CollationKeyAnalyzer

extends Analyzer

Filters `KeywordTokenizer` with `CollationKeyFilter`.

Converts the token into its `CollationKey`, and then encodes the CollationKey with `IndexableBinaryStringTools`, to allow it to be stored as an index term.

WARNING: Make sure you use exactly the same Collator at index and query time -- CollationKeys are only comparable when produced by the same Collator. Since `RuleBasedCollator`s are not independently versioned, it is unsafe to search against stored CollationKeys unless the following are exactly the same (best practice is to store this information with the index and check that they remain the same at query time):

1. JVM vendor
2. JVM version, including patch version
3. The language (and country and variant, if specified) of the Locale used when constructing the collator via `Collator.getInstance(java.util.Locale)`.
4. The collation strength used - see `Collator.setStrength(int)`

The `ICUCollationKeyAnalyzer` in the icu package of Lucene's contrib area uses ICU4J's Collator, which makes its its version available, thus allowing collation to be versioned independently from the JVM. ICUCollationKeyAnalyzer is also significantly faster and generates significantly shorter keys than CollationKeyAnalyzer. See http://site.icu-project.org/charts/collation-icu4j-sun for key generation timing and key length comparisons between ICU4J and java.text.Collator over several languages.

CollationKeys generated by java.text.Collators are not compatible with those those generated by ICU Collators. Specifically, if you use CollationKeyAnalyzer to generate index terms, do not use ICUCollationKeyAnalyzer on the query side, or vice versa.

Constructor Summary
`CollationKeyAnalyzer(Collator collator)`

Method Summary
`TokenStream` | `reusableTokenStream(String fieldName, Reader reader)` Creates a TokenStream that is allowed to be re-used from the previous time that the same thread called this method.
`TokenStream` | `tokenStream(String fieldName, Reader reader)` Creates a TokenStream which tokenizes all the text in the provided Reader.

Methods inherited from class org.apache.lucene.analysis.Analyzer
`close, getOffsetGap, getPositionIncrementGap, getPreviousTokenStream, setPreviousTokenStream`

Methods inherited from class java.lang.Object
`clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

Constructor Detail

### CollationKeyAnalyzer

    public CollationKeyAnalyzer(Collator collator)

Method Detail

### tokenStream

    public TokenStream tokenStream(String fieldName,
                                   Reader reader)

  Description copied from class: `Analyzer`
  Creates a TokenStream which tokenizes all the text in the provided Reader. Must be able to handle null field name for backward compatibility.

  Specified by:
    `tokenStream` in class `Analyzer`

### reusableTokenStream

    public TokenStream reusableTokenStream(String fieldName,
                                           Reader reader)
                                    throws IOException

  Description copied from class: `Analyzer`
  Creates a TokenStream that is allowed to be re-used from the previous time that the same thread called this method. Callers that do not need to use more than one TokenStream at the same time from this analyzer should use this method for better performance.

  Overrides:
    `reusableTokenStream` in class `Analyzer`
  Throws:
    `IOException`

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD