私の使用例は、オンラインメディアのタイトルを保持するインデックスです。データのプロバイダーは、カテゴリのリストを各タイトルに関連付けます。SolrJを使用して、注釈付きのPOJOクラスを介してインデックスを設定しています
例えば
@Field("title")
private String title;
@Field("categories")
private List<Category> categoryList;
関連するPOJOは
public class Category {
private Long id;
private String name;
...
}
私の質問には2つの部分があります。
a）SolrJを介してこれは可能ですか？ドキュメントには文字列のリストを使用した@Fieldの例のみが含まれているため、シリアル化/マーシャリングは単純なタイプのみをサポートしていると思いますか？
b）これを保持するためにスキーマをどのように設定しますか？私は単純に、必要なフィールドでmultiValued = trueを設定する必要があるだけの仮定を持っています。これはすべて魔法で機能します。
私はこれを実装し始めたばかりなので、どんな応答も高く評価されます。
答えはあなたが思ったとおりです：
a）使用できるのは単純なタイプのみです。したがって、同じタイプのリスト（例：String）が作成されます。重要なのは、luceneドキュメント内で複雑な型を表現できないため、それらも逆シリアル化しないことです。
b）問題は、「ドキュメントストア」でリレーショナル思考を表すことです。それはおそらく特定の点でのみ機能します。Luceneドキュメント内のカテゴリを表現する場合は、文字列を使用するだけで、IDを保存する必要もありません。
IDも保存する唯一のポイントは、検索とは別にRDBMSでルックアップを実行する場合です。これを行う場合は、IDとカテゴリ名がソフトリンクされていることを確認する必要があります。これはすべての1：n関係に対して機能しているわけではありません。（n関連テーブルが必須フィールドのみで構成される1：nリレーションはすべて可能です。オプションのフィールドがある場合は、可能であればフィールドに空の定数を埋めるなどのフィールドを配置する必要があります）。
ただし、これらの1：n関係がスパースでない場合、実際にフィールドをドキュメントに追加する順序を維持すると、その可能性は低くなります。したがって、リストを並べ替えない場合は、カテゴリリレーションのケースを表すことができます。
位置0 ... nの値でインスタンス化する場合、このカテゴリを返すメソッドを実装できます。したがって、最初のカテゴリが必要な場合の解決策は、このカテゴリに関連するすべてのリストの位置0になります。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加