Hibernate Search不会基于对“计算”值的更改来重新编制索引

Question

We use Hibernate Search (4.1) throughout our application to manage searching and indexing of resources, but sometimes need to manage "calculated" values in the index, eg, calls to @IndexEmbedded or @Field attached to getters without actual properties:

    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
};

but calling saveResource does not cause HibernateSearch to reindex. Shouldn't it?

Answer 1

HibernateSearch 4.1 (or anything after 3.4) uses 'smart' checks to see whether reindexing needs to happen, which matches the @IndexedEmbedded calls to Hibernate's persisted fields. If these do not match, than Hibernate Search does not reindex the object, because the checks do not see anything that matches, and thus will not call reindex. This is likely because HibernateSearch would have to either perform tremendous amounts of reflection and introspection on indexed fields to determine whether underlying values have changed, or calculate and store the result of each call such that it can determine whether the value has changed or not, thus both slowing down the reindexing process and/or bloating the lucene index with a stored hash or entire result value. Probably best to simply either taint a field that causes the reindexing, or manually reindex the object at the end.