I was debugging a slow member-add operation, which took 10+sec. As soon as I removed the embedded search field Member.person, the action was instant again.

It turns out that reindexing the Member instance, will also trigger a reindex of the Person entity (member.person) , even when the Person has no embedded search field (memberships is not searchable). The reindex of Person then triggers a reindex of all entities that have Person as embedded searchfield, i.e. all Member entities that have this person set as member.person. So it’s likely that the 1495 reindexed Member-instances cause the action to be this slow. Hopefully this is a configuration issue or something we can overcome.

Submitted by Elmer van Chastelet on 9 December 2016 at 14:30

Maybe it’s caused by the way WebDSL changes a collection. If a member is added to Person.memberships, and it creates a whole new collection that is set into this property, then yes, it will trigger a reindex of all the Member entities in Person.memberships. Something to investigate.

After some more debugging I see that HSearch will reindex the whole “index-graph”, whenever it indexes an embedded entity.
For instance, when I make a change in the searchable property Person.fullname, that Person instance will be reindexed. This Person instance is also embedded in other searchable entities, like in ConferenceEdition.editors (you can search conference editions for which a person is editor). The generated code has the @ContainedIn annotation on the inverse relation of such embedded search field, in this case: Person.editorOf (type of Set<ConferenceEdition>). A change to a searchable property of Person will then trigger a reindexation of all instances in Person.editorOf. Nothing special here, and this is how it should work.

However, as multiple ConferenceEdition instances will also be reindexed, the story repeats itself at this level, even when ConferenceEdition is only indexed up to depth level 1. And this is wrong, because we know that entities having ConferenceEdition as embedded search field, will only index the simple properties of ConferenceEdition (because of depth=1), and thus there is no change in indexed fields. Only the fields at level 2 are changed (ConferenceEdition.editors.fullname).

In numbers, when I change my full name (and I’m editor of many conference editions), it reindexes many unrelated entities, causing this change to be extremely inefficient.

Member - 2242
Person - 1
ConferenceEdition - 81
Track - 96
Event - 1017
ProgramSlot - 1029