Change in searchable property can trigger updating whole graph of searchable entities
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 theSubmitted by Elmer van Chastelet on 9 December 2016 at 14:30
Memberinstance, will also trigger a reindex of the
member.person) , even when the
Personhas no embedded search field (
membershipsis not searchable). The reindex of
Personthen triggers a reindex of all entities that have
Personas embedded searchfield, i.e. all
Memberentities 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.
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
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
Personinstance will be reindexed. This
Personinstance 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
@ContainedInannotation on the inverse relation of such embedded search field, in this case:
Set<ConferenceEdition>). A change to a searchable property of
Personwill then trigger a reindexation of all instances in
Person.editorOf. Nothing special here, and this is how it should work.
However, as multiple
ConferenceEditioninstances will also be reindexed, the story repeats itself at this level, even when
ConferenceEditionis only indexed up to depth level 1. And this is wrong, because we know that entities having
ConferenceEditionas 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 (
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
Log in to post comments