Hi All, I recently reviewed how Polaris events are persisted, which is a prerequisite for implementing both the Iceberg event proposal [1] and the event API in Polaris [2]. I identified two areas for improvement: it appears that we only persist two types of events, and Polaris allows only a single event listener. Because of this limitation, we cannot, for example, persist events in the database *and* send them to CloudWatch at the same time.
Regarding the first problem, it seems that the transformation of most service events to event entities is missing from PolarisPersistenceEventListener [3]. Supporting each service event would likely require implementing a transformation for every event type, which could result in more than 150 separate methods or switch cases. The event flattening approach in [4] doesn't seem to help much here, as it replaces roughly 150 classes with about 150 switch branches. At the moment, I do not yet have a good idea how we could simplify this transformation. In the worst case, we would need to implement a large number of branches. As for the second problem, I am considering using the Quarkus event-bus [5] for the PolarisEventListener implementations. This would hopefully keep the listeners configurable, allowing individual listeners to be enabled or disabled while also making it possible for multiple listeners to consume Polaris events simultaneously. What do you think? Nandor [1] https://docs.google.com/document/d/1WtIsNGVX75-_MsQIOJhXLAWg6IbplV4-DkLllQEiFT8/edit?tab=t.0 [2] https://github.com/apache/polaris/pull/3924 [3] https://github.com/apache/polaris/blob/main/runtime/service/src/main/java/org/apache/polaris/service/events/listeners/PolarisPersistenceEventListener.java#L39 [4] https://lists.apache.org/thread/xonxwf9b38t9cxo841r0hn1b34plf7og [5] https://quarkus.io/guides/reactive-event-bus
