Sometimes you need to store stuff in the index for one purpose but as a result of embedded relations this may oversize another index.

Let's say we have a user


Now for purposes of loading neighbourhoods quickly, we store these in the index directly
However, when we store a User, we're not really interested in neighbourhoods, just city, country and region ids.
If we use depth = 2, we are not getting the Region, And if we use depth = 3, we're getting the unwanted Neighbourhoods

Because indexedEmbedded doesn't allow us to exclude relations, when we store a user with a city such as New York, his index record will have all of New York's neighbourhoods. You can see how that would grow the index very quickly.

What is the best way to avoid this kind of behaviour?
It seems to me that a classbridge for this would be an inelegant solution. You would have to do quite a bit of manual coding, checking for nulls etc. It also probably doesn't benefit from all the smart dirty checking that HSearch has, leading to more indexing overhead.

It would really be nice to have a more sophisticated approach than depth to specify what to index. I would love to have an additional tag that allows me to specify the fields to index in an embedded relation.

Marc

That's correct, we have better ideas, but would love to hear your opinion too, as we're argumenting on how it should be done exactly:
https://github.com/hibernate/hibernate-search/pull/156

It's a very interesting discussion and it looks like this would solve my use case.

I also think that there may be differences in the paths to index depending on the root Indexed entity.
Say if
we have


could be different than


Your solution allows to this to be resolved. One thing I can see is that you probably get the situation that in order to avoid some unwanted relations you have to specify a very low depth and add a lot of manual index fields at the root Indexed Entity.

But in the end that is a small price to pay to have the option. But it does raise the idea of having a reverse selection. In stead of "additionalPaths", also have the option "excludePaths". That may in many cases make a lot more sense.

I also wonder how this would work in classbridge scenario's?

My two cents.

Marc

For the sake of others having the same problem, this was solved: http://in.relation.to/Bloggers/NewPaths ... KnowBetter

Thanks Marc for helping on this!