Custom Pre/Post indexing logic?

Hibernate Search
1

Hello - I’ve got an odd question I’m hoping has a solution. I’m currently running:

  • JDK 21
  • Hibernate Search: 6.2.4.Final
  • Hibernate-core 5.6.15.Final
  • AWS OpenSearch 1.2

I’ve requirements to intercept the indexing process on an entity update and perform before and after custom processing. The processing is related to other data contained within the index (probably not relevant). Is there a way to register or inject this type of logic? The JPA entity listeners don’t seem to be the correct choice here as the processing I want to perform should hopefully:

  • only occur when a change has been made to the properties that require a re-index (hibernate search is kindly nice enough to know if the mutations to the entity requires an index). JPA listener is called on any update and from what I can tell doesn’t expose the properties changed
  • JPA listeners are less helpful since the parent indexed entity is mapped to other indexed/embedded entities.

Perhaps a hibernate entity listener is the way to go - at least that appears to provide the before/after changes I can key off of to determine if I need to perform my logic or not? I’d also like to maintain the write-sync strategy if possible to maintain performance - but one step at a time.

Thanks for any help!

Cheers!

2

Hey,

Thanks for reaching out. Hmm, indexing plans do not have the callbacks/listeners you could use…
Depending on what exactly you want to do, you might try intercepting the requests to the search cluster using the ElasticsearchHttpClientConfigurer if you just need to know when requests are sent … (see Hibernate Search 7.2.1.Final: Reference Documentation).
If you have to compare the previous values … then yes, the Hibernate ORM event listener would probably be what you want.
Maybe you can share a bit more on what kind of “before and after custom processing” you want to perform?

3

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:

  1. an indexed field (nested as well)
  2. 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!