According to the <a href="https://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/#search-mapping-associated" rel="nofollow">spec</a>, when <em>@IndexedEmbedded points to an entity, the association has to be directional and the other side has to be annotated with @ContainedIn. If not, Hibernate Search has no way to update the root index when the associated entity is updated</em>.
Am I right to assume the word <em>directional</em> should be <em>bi-directional</em>? I have exactly the problem that my index is not updated. I have one-directional relationships, e.g. person to order but the order does not know the person. Now when I change the order the index is not updated.
If changing the associations to become bi-directional is no option which possibilities would I have to still use hibernate-search? Would it be possible to create two separate indices and to combine queries?Answer1:
Am I right to assume the word directional should be bi-directional?</blockquote>
Yes. I will fix this typo.<blockquote>
If changing the associations to become bi-directional is no option which possibilities would I have to still use hibernate-search?</blockquote>
Person is indexed and embeds
Order doesn't have an inverse association to
Person, then Hibernate Search cannot retrieve the
Persons that have to be reindexed when an
Thus you will have to reindex manually: <a href="https://docs.jboss.org/hibernate/search/5.11/reference/en-US/html_single/#manual-index-changes" rel="nofollow">https://docs.jboss.org/hibernate/search/5.11/reference/en-US/html_single/#manual-index-changes</a> .
You can adopt one of two strategies:<ol><li>The easy path: reindex all the
Personentities periodically, e.g. every night.</li> <li>The hard path: reindex the affected
Personentities whenever an
Orderchanges. This basically means adding code to your services so that whenever an order is created/updated/deleted, you run a query to retrieve all the corresponding persons, and reindex them manually. </li> </ol>
The first solution is fairly simple, but has the big disadvantage that the
Person index will be up to 24 hours out of date. Depending on your use case, that may be ok or that may not.
The second solution is prone to errors and you would basically be doing Hibernate Search's work.
All in all, you really have to ask yourself if adding the inverse side of the association to your model wouldn't be better.<blockquote>
Would it be possible to create two separate indices and to combine queries?</blockquote>
Technically, if you are using the Lucene integration (not the Elasticsearch one), then yes, it would be possible.
But:<ul><li>you would need above-average knowledge of Lucene.</li> <li>you would have to bypass Hibernate Search APIs, and would need to write code to do what Hibernate Search usually does.</li> <li>you would have to use experimental (read: unstable) Lucene APIs.</li> <li>I am unsure as to how well that would perform, as I never tried it.</li> </ul>
So I wouldn't recommend it if you're not familiar with Lucene's APIs. If you really want to take that path, here are a few pointers:<ul><li>How to use the index readers directly: <a href="https://docs.jboss.org/hibernate/search/5.11/reference/en-US/html_single/#IndexReaders" rel="nofollow">https://docs.jboss.org/hibernate/search/5.11/reference/en-US/html_single/#IndexReaders</a></li> <li>Lucene's documentation for joins (what you're looking for is query-time joins): <a href="https://lucene.apache.org/core/5_5_5/join/org/apache/lucene/search/join/package-summary.html" rel="nofollow">https://lucene.apache.org/core/5_5_5/join/org/apache/lucene/search/join/package-summary.html</a></li> </ul>