Hi Alex,

+1 to all three counts.

As for the SQL migration script, is event persistence a fully supported
feature or a "beta"... TBH, I do not recall how it was presented to users.
WDYT?

Cheers,
Dmitri.

On Wed, Oct 22, 2025 at 9:44 AM Alexandre Dutra <[email protected]> wrote:

> 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
>

Reply via email to