sorry for the late reply, I found this email of yours in my spam folder.
On 12 August 2015 at 16:43, Martin Braun <martinbraun123(a)aol.com> wrote:
I guess it's useful in some edge cases where the user wants to search
different entities with one query. As long as everything is in the same index
scoring is a lot easier (I don't know if it even works otherwise). I guess
that could be done by indexing a common supertype, but sometimes that's not possible.
I don't get the filtering out part though. Doesn't the query
API take care of that?
If not, I think it should definitely be doing that (query for the actual class).
Correct, the user of Hibernate Search doesn't have to think about it,
but we still have to perform the filtering, which costs some CPU and
IO for each operation.. always nice if we can avoid it. Although
specifically filtering on a keyword is something Lucene is pretty good
For example I'ld like to convert our Id encoding and our "class_type"
encoding into using DocValues, but we'd need tome performance tests to
From: Gunnar Morling <gunnar(a)hibernate.org>
To: hibernate-dev <hibernate-dev(a)lists.jboss.org>
Sent: Wed, Aug 12, 2015 4:30 pm
Subject: [hibernate-dev] [HSEARCH] Usefulness of index sharing
Hibernate Search aficionados,
I am wondering what that's the rationale for
offering the feature of
index sharing .
The ref guide says "there is
really not much benefit in sharing
indexes". It complicates queries, as an
additional filter on the type
field must be applied in case of targeting only
one entity using a
Should we consider to drop this feature in
hibernate-dev mailing list