1

アプリケーション全体でHibernateSearch（4.1）を使用してリソースの検索とインデックス作成を管理しますが、インデックス内の「計算された」値を管理する必要がある場合があります。たとえば、実際のプロパティのないゲッターにアタッチされた@IndexEmbeddedまたは@Fieldの呼び出しです。

    public class Resource {
            @ManyToMany(...)
            private List<Keyword> keywords = new ArrayList<Keyword>();


            public List<Keyword> getKeywords() {
                    return keywords;
            }

            public List<Keyword> setKeywords(List<Keyword> keyword>) {
                    this.keywords=keywords;
            };


            @IndexedEmbedded
            public List<Keyword> getIndexedKeywords() {
                    List<Keyword> toReturn = new ArrayList<Keyword>();
                    for (Keyword keyword: getKeywords()) {
                            if (keyword.isIndexed) {
                                    toReturn.add(keyword);
                            }
                    }
                    return toReturn;
            }

    }

..。

public void saveResource(Resource resource, Collection<Keyword> keywords) {
        resource.getKeywords().retainAll(keywords);
        resource.getKeywords().addAll(keywords);
        session.saveOrUpdate(resource);
        // will trigger a persist in the database correctly, but will not trigger a reindex
};

ただし、saveResourceを呼び出しても、HibernateSearchのインデックスは再作成されません。いけませんか？

4

1 に答える 1

0

HibernateSearch 4.1（または3.4以降）は、「smart」チェックを使用して、インデックスの再作成が必要かどうかを確認します。これは、Hibernateの永続化フィールドへの@IndexedEmbedded呼び出しと一致します。これらが一致しない場合、Hibernate Searchはオブジェクトのインデックスを再作成しません。これは、チェックで一致するものが検出されないため、reindexが呼び出されないためです。これは、HibernateSearchがインデックス付きフィールドに対して膨大な量のリフレクションとイントロスペクションを実行して、基になる値が変更されたかどうかを判断するか、値が変更されたかどうかを判断できるように各呼び出しの結果を計算して保存する必要があるためと考えられます。インデックスの再作成プロセスを遅くすること、および/または保存されたハッシュまたは結果値全体でluceneインデックスを肥大化させることの両方。おそらく、インデックスの再作成を引き起こすフィールドを単純に汚染するのが最善です。

于 2012-08-09T20:23:16.297 に答える