Totally agree. In fact, other enum types (e.g., PolarisPrivilege, PolarisEntityType) use numeric ids in storage to decouple naming in code from the values we persist in the database. I'd recommend continuing with that pattern.
Mike On Wed, Oct 22, 2025 at 10:38 AM Dmitri Bourlatchkov <[email protected]> wrote: > 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 > > >
