Thanks for the quick reply. I’ll take a look a the class you mentioned as see if that might be something we could leverage.
For reference, the application in question here stores/indexes personnel and uses criteria stored in the database to segment people in a generic manner. For example - a segment created for “all people who reside in FR and have a hire date before 12-10-2020”.
The ask is to have notifications sent out after updates to a person. For example - if the above person is updated to live in DE - then the alert would send a notification indicating they were “removed” from that example segment and potentially “added” to another segment related to residents of Germany. Given the application only stores the “criteria” for the segments - it needs to ask OpenSearch for a given individual’s segment membership prior to the change, then after the change in order to resolve any differences in segmentation.
This is once of the reasons I have a strong preference for using the hibernate listener - since this notification doesn’t come for free. Preference is to only do this logic/processing when a change has been made to the indexed entity that is:
- an indexed field (nested as well)
- an indexed field that can be used for segmentation
Other changes to the hibernate domain object - even if they are indexed properties - so not need this processing since they cannot mutate the segmentation.
Let me know if this makes things more confusing!
Cheers!