Hi Robert, I did not see your message on the PR. It is a fair comment. Can you please cut an issue so someone can pick this up? If I get some time, I may do so but cannot commit to it right now.
Best, Adnan Hemani On Wed, Jan 7, 2026 at 3:25 AM Robert Stupp <[email protected]> wrote: > Hi all, > > I am not objecting to the change it, but I think the same refactoring > should happen to corresponding events for views as well to retain > consistency. > > Robert > > On Wed, Dec 3, 2025 at 10:24 PM Adnan Hemani via dev > <[email protected]> wrote: > > > > Hi folks, > > > > I've cut #3195 <https://github.com/apache/polaris/pull/3195> on the > basis > > of this discussion. PTAL! > > > > Best, > > Adnan Hemani > > > > On Wed, Nov 26, 2025 at 12:33 PM Adnan Hemani < > [email protected]> > > wrote: > > > > > 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 > > >> > > > > >> > > > >> > > > >
