[hibernate-dev] [HSEARCH] Wrong query results when embedding *-to-many associations

[Hardy Ferentschik]

> in the forum [1] a user runs into a variant of the old problem where
> boolean searches on different fields of the elements of an embedded
> association return wrong results due to hits in different elements of
> the collections.
> 
> What is our recommendation/answer to this type of question? I've seen
> it popping up several times, it seems to be a common trap for users.
> Having an FAQ entry for this would be nice.

I don't think the answer is "it depends" ;-)
I guess there are two main strategies:

#1 Use a custom field bridge in which you can index a combination of fields.
   Target this field when querying
#2 Turn the problem around. In many cases both entities (the entity holding  
   the association as well as the associated entity) are indexed. Target the
   associated entity with your query and navigate via the relation (provided 
   it is bi-directional) to the "parent" entity.

I think a FAQ entry makes sense, maybe with a more detailed example and description.
Or it could be added to the docs itself as a note to association querying.

> ES btw. nicely avoids this by storing nested objects in separate
> "hidden" documents [2]. This allows to run queries without getting
> results from different collection elements. It'd be a nice addition to
> do something similar in HSEARCH?

It would be an interesting feature indeed. I would imagine though that implementing 
it using additional Document instances could be quite tricky from our side.
The whole engine is based around the concept of single Document per entity. Also
the query part would need changing/extending.

I would think that ES uses query time joins for that [1]. We have multiple issues
for making use of query time joins as well - HSEARCH-1631 [2], HSEARCH-1237 [3].
I guess one would need to start with thinking through how this would work from
a configuration point of view and which changes are then required in the engine.

IMO this would be a high value feature (much higher than others we keep discussing).

--Hardy


[1] http://blog.trifork.com/2012/01/22/query-time-joining-in-lucene/
[2] https://hibernate.atlassian.net/browse/HSEARCH-1631
[3] https://hibernate.atlassian.net/browse/HSEARCH-1237
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150825/f4b2b0d8/attachment.bin