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