The main advantage compared to client-side event sourcing would be the ability to detect "batch" changes caused by update/delete queries, which currently are not detected.
For example if the user updates the property {{name}} in a thousand {{Person}} entities using {{UPDATE Person p SET p.name = CONCAT(p.name, 'foo')}}, this change currently is never detected by Hibernate Search. The user has to take care to reindex affected entities manually.
Once [https://hibernate.atlassian.net/browse/HSEARCH-3280|https://hibernate.atlassian.net/browse/HSEARCH-3280|smart-link] is addressed, we will have most of the infrastructure ready to support Debezium in Hibernate Search. The main problem will be to create a Debezium plugin that allows to:
* Define the events we're interested in at the Hibernate ORM entity level, instead of the table level (i.e. translate"I'm interested in property {{myEmbeddable.property1}} of entity {{MyEntity}}" into "I'm interested in column {{myEmbeddable_property1}} of table {{myentity}}".
* Ideally, send entity-scoped events instead of table-scoped event, with the same format as what we envision for entity change events in [https://hibernate.atlassian.net/browse/ HSEARCH-3281|https://hibernate.atlassian.net/browse/HSEARCH-3281|smart-link]
Optimistically planning this for 6.1, but we will need to work very hard with the Debezium team to address the two points above.
Interesting, related documentation: [https://docs.confluent.io/platform/current/streams/architecture.html#stream-partitions-and-tasks|https://docs.confluent.io/platform/current/streams/architecture.html#stream-partitions-and-tasks] |
|
