Please make sure you create a new issue to track this, or I will forget!
Also, Adam was working on a test but maybe Adrian you have one too? Without a test it's hard for me to figure out the exact scenario; if somebody sends one we will attempt to fix it (or if you want to try fixing it yourself and figure as a project contributor that's great too, I can give some directions).
For inspiration on how to make a test, the one committed as part of this issue by Tom and myself should be a good starting point (see the sources tab for a list of changes related to this issue).

This bug is also affecting me in a highly detrimental fashion. (its causing over 1million rows to be loaded and crashes the server). From reading Adam harris's comment it sounds exactly like my situation. Fortunately for us removing @ContainedIn on the offending collection (as the entity itself isn't directly indexed) resolved the issue for me but its something that either needs clarifying or fixing as It can have disastrous consequences!

I don't understand your comment about UC#1. I know that index "updates" are really deletes and re-adds, but why does each B instance need to be re-indexed at all? Based on HSEARCH-361, since no indexed fields in A were changed, there's nothing to do in B's index. I don't index the row-version field (not even shown in my code snippets). If I were updating the A.name field, then I would understand why all of the B instances need to be rebuilt, but that's not my scenario.

sorry I misread your example as a many-to-many; I think you're right there should be no need to update the index; the problem must hide in how we flag the association to B as "index triggering", being annotated with @ContainedIn, and dirty as well as you're updating it. Thanks, yes we should be able to do better! Looking forward for tests.

Sanne,
I updated my previous comment because I was missing @Indexed. To answer your first question - no, both classes A and B are indexed.

I don't understand your comment about UC#1. I know that index "updates" are really deletes and re-adds, but why does each B instance need to be re-indexed at all? Based on HSEARCH-361, since no indexed fields in A were changed, there's nothing to do in B's index. I don't index the row-version field (not even shown in my code snippets). If I were updating the A.name field, then I would understand why all of the B instances need to be rebuilt, but that's not my scenario.

Regarding your comments on UC#2, I am not using @DynamicBoost or @ClassBridge. I'll look into the test case example and see about creating one for you.

Thanks for your help.

Hi Adam,
thanks for the report. I guess only B is @Indexed right?
About use case #1, changing the value of the Collection<B> will require a re-indexing of each B instance which was in the collection before, or after. Remember an index is not update-able, so we have to rebuilt the index line for each B instance from scratch.
Use case #2 should NOT trigger indexing however, unless A is being annotated with @DynamicBoost or @ClassBridge; if that's not the case, could you please provide a test case? I'll be glad to look into it. To create one, please have a look at what Tom and me created for this issue: org.hibernate.search.test.engine.optimizations.CollectionUpdateEventTest, it would be nice to patch that to cover your case as well.