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
yo...@hibernate.org
On 9 May 2017 at 16:09, Gunnar Morling <gun...@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@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
