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.