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