> I had written the "why" on HSEARCH-2616, but to clarify here: [...]
Thanks. So the problem is that we may not be able to update the batch state
upon failure, in which case we would use the less-safe AddLuceneWork upon
restart.
If we had some way to store the information "this partition has start
On 27 April 2017 at 15:11, Yoann Rodiere wrote:
> I wonder, what's the benefit for HSEARCH-2616? Do you want to have that
> field so that we can just use AddLuceneWorks everywhere, and run targeted
> delete operations when we start a partition? If so, is it as a fallback
> solution, if what I prop
I wonder, what's the benefit for HSEARCH-2616? Do you want to have that
field so that we can just use AddLuceneWorks everywhere, and run targeted
delete operations when we start a partition? If so, is it as a fallback
solution, if what I proposed cannot be implemented, or as a better
alternative? N
To better implement recovery operations during MassIndexer
[HSEARCH-2616] - specifically in the context of the upcoming JBatch
based implementation - I'm considering the benefits of adding one more
field the the Lucene index for our internal purposes.
This new field is only useful for Hibernate Se
