[hibernate-dev] Questions on HS + ES

[Yoann Rodiere]

Hi,

> * Can we have multiple indexes for the same entity, with different
> fields, geared towards different use cases?

No, it's not currently possible. Each entity is mapped to a single index.
But you can map each property of your entity to multiple index
"properties", so you can actually handle multiple use cases in a single
index.
We could probably think about adding the feature you describe, and it may
even not be very difficult (expect a few things that we'll have to do
anyway). But I fail to see the added value compared to having all those
fields in a single index. Performance-wise, I doubt it would change
anything, and on the user side the mapping would likely become harder to
understand (especially uses of @IndexedEmbedded).

> * How could we deal with authorization for seeing specific ES query
> results? I reckon that's something to mostly (solely?) handle on the
> ES side?

Hibernate Search itself does not provide any authorization features.
You can add security either:

   - on the ES side (with Shield) to define what the *application* is
   allowed to access (only the application scope makes sense here, since we
   use a single username for every request). This would involve updating index
   settings after they've been created or creating index templates before the
   indexes are created.
   - on the client side to define what a specific *user* is allowed to
   access, for example by annotating your services with Spring Security, which
   allows both pre-execution checks ("is this query parameter allowed") and
   post-execution checks ("is every result in the result set visible for the
   given user").

> * Are dynamic analyzers supported for the ES backend?

Nope, as mentioned in the docs [1]. They simply cannot be supported as is,
since with Elasticsearch, analyzers cannot be chosen when indexing, only
when creating the mapping.

> * And a wish for the docs: make clear which kind of changes towards
> mapped entities require a re-index run?

Any change that would result in already indexed entities to be indexed
differently: adding a new field based on pre-existing data, renaming a
field, changing its encoding (text to numeric for instance), changing how
it's analyzed (tokenizer, filter), making it stored while it previously
wasn't...
It's easier to state which changes do *not* require a re-index run,
actually:

   - new indexes/fields based on currently empty data, e.g. a new property
   in an entity that is currently empty for every entity, or a new index
   mapping for an entity that hasn't any database row yet.
   - feature reduction, e.g. making a previously stored field not stored,
   or removing a field. The data will stay in the index, we just won't use it
   nor update it anymore.

I created a ticket about this: HSEARCH-2715 [2].


Of course the limitations I just mentioned above are not carved in stone.
Hibernate Search evolves continuously, and if user feel like a specific
feature is missing, they can request it through JIRA.

[1]
https://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/#elasticsearch-limitations
[2] https://hibernate.atlassian.net/browse/HSEARCH-2715


Yoann Rodière
Hibernate NoORM Team
yoann at hibernate.org

On 9 May 2017 at 16:09, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> I recently got some good questions on Hibernate Search + Elastisearch:
>
> * Can we have multiple indexes for the same entity, with different
> fields, geared towards different use cases?
> * How could we deal with authorization for seeing specific ES query
> results? I reckon that's something to mostly (solely?) handle on the
> ES side?
> * Are dynamic analyzers supported for the ES backend?
> * And a wish for the docs: make clear which kind of changes towards
> mapped entities require a re-index run?
>
> Any replies would be welcome.
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>