Hi all, Currently, Polaris manages over 150 event types, but they lack proper identifiers, leading to the problematic use of Java class names to represent the event types.
For instance, PolarisPersistenceEventListener relies on Java class names to store event types in the database [1]. Thus, renaming or moving an event class could inadvertently break this listener, or any other listener doing something similar. Moreover, if we were to introduce a configuration to manage event types (which I think we'll have to do eventually), we'd need to use Java class names again, out of better options. Consider a hypothetical configuration example that highlights this issue: polaris.event-listener.enabled-event-types=\ org.apache.polaris.service.events.IcebergRestCatalogEvents.AfterRefreshTableEvent,\ org.apache.polaris.service.events.IcebergRestCatalogEvents.AfterCommitTableEvent It's obvious that listing event types in such a way is not only verbose, but also cryptic for users. It introduces an unnecessary tight coupling between user-facing configuration and Polaris internals. To address these concerns, I would like to promote event types to first-class citizens in Polaris: 1. Introduce the concept of an event type with a unique, logical ID (e.g., BEFORE_CREATE_CATALOG). This could be enforced through a Java enum for uniqueness. 2. Add a new method, PolarisEventType type(), to the PolarisEvent interface. This is not only informative; it could serve e.g. as a type discriminator when serializing events. 3. Replace class names with logical IDs, both in configuration and when storing events in the database. Note: The last item represents a breaking change and may require a SQL migration script. I'm curious to hear your thoughts. Thanks, Alex [1]: https://github.com/apache/polaris/blob/3b4b0169032216d85d48130ad43285f86e886e3c/runtime/service/src/main/java/org/apache/polaris/service/events/listeners/PolarisPersistenceEventListener.java#L44
