我在其中一个实体类上使用Hibernate Search和条件索引。该实体的@Indexed
注释指定了一个自定义拦截器,它可以防止某个状态的实例被编入索引。
这完全符合预期。但是,我注意到当我使用MassIndexer
重新索引所有内容时,它会忽略该实体类上的自定义拦截器。我已经通过调试模式确认了拦截器永远不会被调用,并且该实体的所有实例都被编入索引,即使它们符合被跳过的条件。
我错过了什么吗?在Hibernate Search中是否有一种重构索引的方法,它可以在实体类中使用任何自定义拦截器吗?
我尝试使用此代码段切换到Sanne建议的“旧式”方法:
FullTextSession fullTextSession = Search.getFullTextSession(session);
fullTextSession.setFlushMode(FlushMode.MANUAL);
fullTextSession.setCacheMode(CacheMode.IGNORE);
fullTextSession.beginTransaction();
// Kill the current index
fullTextSession.purgeAll(MyEntity.class);
int batchSize = 10;
ScrollableResults results = fullTextSession.createCriteria(MyEntity.class)
.setFetchSize(batchSize)
.scroll(ScrollMode.FORWARD_ONLY);
int index = 0;
while(results.next()) {
// Re-index entites in batches of 10, freeing up memory after each batch
index++;
fullTextSession.index(results.get(0));
if (index % batchSize == 0) {
fullTextSession.flushToIndexes();
fullTextSession.clear();
}
}
fullTextSession.getTransaction().commit();
但是,我看到了与MassIndexer
完全相同的行为。不调用MyEntity
上的条件映射拦截器,并且所有MyEntity
实例都被索引,无论它们是否应该被编入索引。
答案 0 :(得分:2)
答案 1 :(得分:0)
我遇到了同样的问题。不幸的是我没有找到任何好的解决方案。我尝试开发自己的解决方案,但我并不为此感到自豪。也许有人可以改进它。
int index = 0;
EntityIndexingInterceptor eii =
((SearchFactoryIntegrator) fullTextSession.getSearchFactory())
.getIndexBindingForEntity(MyEntity.class)
.getEntityIndexingInterceptor();
while(results.next()) {
if (eii.onAdd(results.get(0)) != IndexingOverride.SKIP){ // explit call interceptor
index++;
fullTextSession.index( results.get(0) );
if (index % BATCH_SIZE == 0) {
fullTextSession.flushToIndexes();
fullTextSession.clear();
}
}
}
fullTextSession.flushToIndexes();
我一直在寻找更简单的方法来触发拦截器,但没有成功:(
顺便说一句。 如果您查看EntityIndexingInterceptor声明,您可以看到:
//FIXME should we add onPurge and onIndex?