Hi all, Yes Oleg, that's a good point out - at that time I hadn't questioned the role that the *CommitTableEvents play while looking into the transaction bugs that had been reported. This recommendation is 100% influenced by my findings on that side of things :)
> Are there any that are not covered by existing events? The CommitTransaction API is a bit odd in this manner - today it only generates the (Before/After)CommitTransaction events. So while a user may have updated one/multiple tables(s) as part of the transaction, there is not a specific *UpdateTableEvent that is generated. To maintain parity and specificity while removing the *CommitTableEvents, I will work on generating the necessary *UpdateTableEvent for changes made during a transaction. Best, Adnan Hemani On Tue, Nov 25, 2025 at 3:58 PM Yufei Gu <[email protected]> wrote: > +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 > > > > > >
