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? Note I don't have strong arguments against that solution, I'm just trying to understand the "why".
On adding a hidden field, I wonder what this will mean for Elasticsearch; if we start doing such things, we should clearly and explicitly state in the documentation that targeting existing ES schemas without adapting them to Hibernate Search is not supported. On top of that, it may hurt users upgrading Hibernate Search: Lucene may simply ignore queries against a field that doesn't exist in the index, but I'm not sure Elasticsearch behaves that way when the field isn't even defined in the mapping. So users may have to upgrade their schema just for that. I know Elasticsearch integration is experimental anyway, but what I mean is if we do that, it must be *before* Elasticsearch we drop the "experimental" mention on Elasticsearch integration. Yoann Rodière Hibernate NoORM Team yo...@hibernate.org On 27 April 2017 at 15:59, Yoann Rodiere <yrodi...@redhat.com> 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 proposed cannot be implemented, or as a better > alternative? Note I don't have strong arguments against that solution, I'm > just trying to understand the "why". > > On adding a hidden field, I wonder what this will mean for Elasticsearch; > if we start doing such things, we should clearly and explicitly state in > the documentation that targeting existing ES schemas without adapting them > to Hibernate Search is not supported. > On top of that, it may hurt users upgrading Hibernate Search: Lucene may > simply ignore queries against a field that doesn't exist in the index, but > I'm not sure Elasticsearch behaves that way when the field isn't even > defined in the mapping. So users may have to upgrade their schema just for > that. I know Elasticsearch integration is experimental anyway, but what I > mean is if we do that, it must be *before* Elasticsearch we drop the > "experimental" mention on Elasticsearch integration. > > > Yoann Rodière > Software Engineer, Hibernate NoORM Team > Red Hat > yrodi...@redhat.com > > On 27 April 2017 at 15:23, Sanne Grinovero <sa...@hibernate.org> wrote: > >> 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 Search internals so we >> shouldn't allow it to be targeted by queries, etc.. >> >> There is a single precedent: we already encode the entity name, so >> "hiding fields" is not a new problem that we have to deal with. It >> might be a reason to polish the existing concept and improve the >> encapsulation. >> >> Would anyone have a strong case against this? >> >> Thanks, >> Sanne >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
