+1 on the removal. Here are the reasons: they are not used anywhere AFAIK,
and there are replacements(*UpdateTableEvent, *RegisterTableEvent) with
more consistent names.

Yufei


On Tue, Nov 25, 2025 at 6:11 AM Oleg Soloviov <[email protected]> wrote:

> Hi Adnan,
>
> I was planning to use them since you mentioned you were not going to delete
> it on Polaris slack channel :)
> But I do not mind removing them, if it helps to keep Events API more clear
> and concise, especially in the context of multiple table commit scenarios.
>
> > Most of the APIs that the commit events were signaling now have their own
> instrumented events (such as `UpdateTable`)
> Are there any that are not covered by existing events?
>
> Thanks,
> Oleg
>
> On Mon, Nov 24, 2025 at 9:57 PM Adnan Hemani via dev <
> [email protected]>
> wrote:
>
> > Hi all,
> >
> > I wanted to gauge the community's thoughts on removing
> > (Before/After)CommitTableEvent altogether. Most of the APIs that the
> commit
> > events were signaling now have their own instrumented events (such as
> > `UpdateTable`). Does anyone still have a use of the commit events on
> their
> > own then?
> >
> > Best,
> > Adnan Hemani
> >
>

Reply via email to