Hi, 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). cheers, Martin Braun martinbraun123(a)aol.com www.github.com/s4ke -----Original Message----- From: Gunnar Morling <gunnar(a)hibernate.org&gt; To: hibernate-dev <hibernate-dev(a)lists.jboss.org&gt; 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 [1]. 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 shared index. Should we consider to drop this feature in HS 6? Thanks, --Gunnar [1] https://docs.jboss.org/hibernate/search/5.4/reference/en-US/html_single/#... _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

That's an interesting proposal, as index sharing inherently implies that fields on different types shall not have conflicting mapping (i.e. don't reuse the same field name for a different type). By default we don't share indexes across unrelated types, but also *by default* subtypes are indexed in the same index as their parent - if the parent is indexed as well. The reason is to efficiently map a polymorphic domain: when people search for type X, they implicitly also search for its subtypes as these are valid candidates for the query. Having them all in the same index makes for better result quality and better search performance - as joining multiple IndexReaders to perform a cross - index Query is generally a bad idea, as it's then hard to accurately normalize statistics across different vector spaces, and that's what defines the quality of the search result. At least I believe that *generally* that would give you better results, but that's why we give options, and also why sometimes people might want multiple Domain objects to be stored in the same index: they might be "subtypes" from a domain perspective even if they don't technically use inheritance at the Java level: they might be different types and yet be mapped to some common fields with (hopefully) compatible indexing options. If we were to drop index sharing, then I think it should be fair to also not support multiple types as target for a query anymore; as I'm assuming in this case you'd only share for subtypes of some common parent, and you'd target that common parent exclusively to perform a polymorphic query. So that's the reasons for which it exists; there are some good reasons to not allow it too: as you mention the filtering, but also the very fact that the type information has to be stored in form of classname (typename, in free-form). I think the strongest reason to not allow it is to avoid the inconsistent field mappings, but we could compensate for that with better schema validation - something which seems is getting more necessary anyway. I didn't mean to kill the proposal :) just hoping it helps figure out why someone might need it. Would be nice to think of alternatives out of the box to avoid the filtering. Sanne On 12 August 2015 at 15:30, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote:

On 13 August 2015 at 08:33, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: Yes, not least by myself :) You might have various types which don't share a Java inheritance tree but still have some common property. Could be a simple tagging system, or just the classical example of "title" of a product. Some people will have a Product parent class, some people might not have love for expressing their model in a Java inheritance straight jacket.. a real world large information system seldom follows the Animal examples of text books. Consider also that you might not want to *search* for these different types, but still index them together. E.g. do some computation like what's the most frequently used tag across various types, or implement an auto-suggester field for a UI in which the exact target domain type is yet to be filled in by some follow-up step. So while I agree it doesn't seem a great idea to run a query which could return multiple different (and unrelated - other than by inheritance from Object), there are many other cases; even a mixed-type search is not too hard to handle when using a Projection. Right, any discriminator is quite cheap with Lucene. Just trying to think which benefits it would have, but it's clear I think we need to stick with it. I'll assume the above examples changed your mind ;) Cheers, Sanne

Thanks for the feedback, Andrej! What kind of sharing is this, the one between types of one inheritance hierarchy we discussed or between unrelated types? In case of the latter, what's the reason that you need this? Would be interested to learn about the use case. --Gunnar 2015-08-12 23:17 GMT+02:00 Andrej Golovnin <golovnin(a)gmx.net&gt;: