[hibernate-dev] Hibernate Search: Adding more "hidden" fields to the index

[Yoann Rodiere]

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
yoann at hibernate.org

On 27 April 2017 at 15:59, Yoann Rodiere <yrodiere at 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
> yrodiere at redhat.com
>
> On 27 April 2017 at 15:23, Sanne Grinovero <sanne at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>