karmajunkie が暗示しているように、Sunspot は独自の標準スキーマを使用しています。ここでは、その仕組みについてもう少し詳しく説明します。
Solr スキーマ 101
この議論の目的のために、Solr スキーマは主に 2 つのもので構成されています: 型定義とフィールド定義です。
定義は、その名前、型のtype
Java クラス、および一部の型 (特にテキスト) の場合は、その型の処理方法を構成する XML の従属ブロックを指定することによって、型を設定します。
定義を使用するfield
と、フィールドの名前と、そのフィールドに含まれる値のタイプの名前を定義できます。これにより、Solr はドキュメント内のフィールドの名前とそのタイプ、およびその他のいくつかのオプションを関連付けることができ、そのフィールドの値をインデックスで処理する方法を知ることができます。
Solr はdynamicField
定義もサポートしており、静的フィールド名の代わりに、グロブを含むパターンを指定できます。入力フィールドは、そのタイプを判別するために、これらのパターンと一致する名前を持つことができます。
黒点の従来のスキーマ
Sunspot のスキーマにはfield
、ID やモデル名など、内部で使用されるフィールドの定義がいくつかあります。さらに、Sunspot はdynamicField
定義を自由に使用して、型に基づく命名規則を確立します。
このフィールド命名規則の使用により、Sunspot は、モデルから XML ドキュメントへのマッピングを作成し、Solr によるインデックス作成の準備が整った構成 DSL を定義できます。
たとえば、モデル内のこの単純な構成ブロックは…</p>
searchable do
text :body
end
…のフィールド名を作成するために Sunspot によって使用されますbody_text
。このフィールド名は、スキーマ内の次の定義の*_text
パターンと照合されます。dynamicField
<dynamicField name="*_text" type="text" indexed="true" stored="false" multiValued="true"/>
_text
これにより、接尾辞を持つすべてのフィールドが Sunspot の型の定義にマップされますtext
。Sunspot の schema.xml を見てみると、他のタイプやオプションについても同様の規則が多数あることがわかります。:stored => true
たとえば、このオプションは通常s
、その型のサフィックスに を追加します (例: _texts
)。
実際に Sunspot のスキーマを変更する
クライアントや私自身のプロジェクトでの私の経験では、Sunspot のスキーマを変更するのに適したケースが 2 つあります。まず、text
アプリケーションが必要とするさまざまな機能に基づいて、フィールドのアナライザーを変更します。そして 2 つ目は、Solr アナライザーのよりきめ細かいアプリケーション用に (通常はテキスト型に基づいて) まったく新しい型を作成することです。
たとえば、「ファジー」検索による検索一致の拡張は、言語語幹 (NGram) も使用する特別なテキストベースのフィールドに対する一致で実行できます。text
元のフィールドのトークンは、スペルチェックに入力したり、完全一致を強化したりするために使用できます。text_ngram
また、カスタムまたはのトークンはtext_en
、より厳密な一致が失敗した場合に検索結果を広げるのに役立ちます。
Sunspot の DSL は、フィールドをこれらのカスタム フィールドにマッピングするための 1 つの最後の機能を提供します。type
とそれに対応するdynamicField
定義を設定したら、Sunspot の:as
オプションを使用して、慣習に基づく名前生成をオーバーライドできます。
たとえばngram
、上記のカスタム タイプを追加すると、次の Ruby コードを使用して NGrams でボディを再度処理することになる場合があります。
searchable do
text :body
text :body_ngram, :as => 'body_ngram'
end