Red Hat Training

A Red Hat training course is available for Red Hat JBoss Enterprise Application Platform

14.2.3.2. Named Analyzers

アナライザーの処理は非常に複雑になる可能性があります。このため、Hibernate Search にはアナライザ定義の概念が導入されました。アナライザ定義は、@Analyzer 宣言の多くで再利用でき、以下で構成されています。
  • a name: 定義を参照するために使用される一意な文字列
  • a list of char filters: 各文字型フィルターは、トークン化の前に入力文字を事前処理します。文字型フィルターでは、文字の追加、変更、削除ができます。一般的な使用方法として、文字を正規化する方法があります。
  • a tokenizer: 入力ストリームを個別の単語にトークン化します。
  • a list of filters: 各フィルターは、単語の削除や変更を行い、トークンライザーが提供するストリームに単語を追加することさえあります。
タスクの分離: 文字型フィルターのリストとトークンライザー、およびフィルターの一覧が続きます。これにより、個々のコンポーネントを簡単に再利用でき、(Lego など) 非常に柔軟な方法でカスタマイズされたアナライザーを構築することができます。一般的に、文字型フィルターは文字入力で一部の事前処理を実行し、Tokenizer は、文字入力を TokenFilter によってさらに処理されるトークンに変換してトークン処理を開始します。Hibernate Search は Solr Analyzer フレームワークを使用してこのインフラストラクチャーをサポートします。
注記
一部のアナライザーとフィルターには、追加の依存関係が必要になります。たとえば、スノーボールステマーを使用するには、lucene-snowball jar も含める必要があり、PhoneticFilterFactory には、commons-codecjar が必要です。Hibernate Search のディストリビューションは、lib/optional ディレクトリーにこれらの依存関係を提供します。
Maven を使用する場合、必要なすべての Solr 依存関係は、アーティファクト org.hibernate:hibernate-search-analyzers の依存関係として定義されるようになりました。次の依存関係を追加します。 
<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-search-analyzers</artifactId>
   <version>4.6.0.Final-redhat-2</version>
   <scope>provided</scope>
<dependency>
今すぐ具体的な例を見てみましょう -例14.20「@AnalyzerDef と Solr フレームワーク」。まず、文字型フィルターはファクトリーによって定義されます。この例では、マッピング文字型フィルターが使用され、マッピングファイルに指定されたルールに基づいて入力内の文字が置き換えられます。次にトークナイザーを定義します。この例では、標準トークナイザーを使用します。最後に同じように重要に、のフィルターの一覧がファクトリーによって定義されます。この例では、StopFilter フィルターは、専用の用語プロパティーファイルを読み取ります。フィルターはケースを無視することも予想されます。

例14.20 @AnalyzerDef と Solr フレームワーク

@AnalyzerDef(name="customanalyzer",
  charFilters = {
    @CharFilterDef(factory = MappingCharFilterFactory.class, params = {
      @Parameter(name = "mapping",
        value = "org/hibernate/search/test/analyzer/solr/mapping-chars.properties")
    })
  },
  tokenizer = @TokenizerDef(factory = StandardTokenizerFactory.class),
  filters = {
    @TokenFilterDef(factory = ISOLatin1AccentFilterFactory.class),
    @TokenFilterDef(factory = LowerCaseFilterFactory.class),
    @TokenFilterDef(factory = StopFilterFactory.class, params = {
      @Parameter(name="words",
        value= "org/hibernate/search/test/analyzer/solr/stoplist.properties" ),
      @Parameter(name="ignoreCase", value="true")
    })
})
public class Team {
    ...
}
注記
フィルターと文字型フィルターは、@AnalyzerDef アノテーションで定義された順序で適用されます。順序は重要です。
一部のトークナイザー、トークンフィルター、または文字型フィルターは、設定ファイルやメタデータファイルなどのリソースを読み込みます。これは、ストップフィルターと同意フィルターの例になります。リソース文字セットが仮想マシンのデフォルトを使用していない場合は、resource_charset パラメーターを追加して明示的に指定できます。

例14.21 特定の文字セットを使用したプロパティーファイルの読み込み

@AnalyzerDef(name="customanalyzer",
  charFilters = {
    @CharFilterDef(factory = MappingCharFilterFactory.class, params = {
      @Parameter(name = "mapping",
        value = "org/hibernate/search/test/analyzer/solr/mapping-chars.properties")
    })
  },
  tokenizer = @TokenizerDef(factory = StandardTokenizerFactory.class),
  filters = {
    @TokenFilterDef(factory = ISOLatin1AccentFilterFactory.class),
    @TokenFilterDef(factory = LowerCaseFilterFactory.class),
    @TokenFilterDef(factory = StopFilterFactory.class, params = {
      @Parameter(name="words",
        value= "org/hibernate/search/test/analyzer/solr/stoplist.properties" ),
      @Parameter(name="resource_charset", value = "UTF-16BE"),
      @Parameter(name="ignoreCase", value="true")
  })
})
public class Team {
    ...
}
一度定義されると、アナライザー定義は、次のように @Analyzer 宣言で再利用できます。例14.22「名前でアナライザーを参照する」。

例14.22 名前でアナライザーを参照する

@Entity
@Indexed
@AnalyzerDef(name="customanalyzer", ... )
public class Team {
    @Id
    @DocumentId
    @GeneratedValue
    private Integer id;

    @Field
    private String name;

    @Field
    private String location;

    @Field 
    @Analyzer(definition = "customanalyzer")
    private String description;
}
@AnalyzerDef で宣言された Analyzer インスタンスは、SearchFactory の名前でも利用できます.これは、クエリーを構築する際に非常に便利です。 
Analyzer analyzer = fullTextSession.getSearchFactory().getAnalyzer("customanalyzer");
クエリー内のフィールドは、共通の「言語」を伝えるためにフィールドのインデックス作成に使用するものと同じアナライザーで分析する必要があります。クエリーとインデックス作成プロセス間で同じトークンが再利用されます。このルールには例外がありますが、ほとんどの場合に当てはまります。実際に何を実行しているのかが分からない限り、それに従ってください。
バグの報告