Thanks for the review. I've responded to the specific comments on the PR. By definition events enable a large degree of user-specific customization so not all use cases are known in advance. It's important to view them as iterative and the initial PR doesn't need to try to cover everything.
Re: future proofing, I don't think event listeners are a special case. We should always consider how our changes affect existing users. There's a balance, as users pulling a new version of Polaris can't expect nothing to have changed. Best, Andrew On Tue, Mar 18, 2025 at 3:47 AM Robert Stupp <sn...@snazy.de> wrote: > Thanks Andrew for the effort. I'm very much in favor of having the > ability to receive events. > > From the doc and from the implementation it's hard to reason about the > actual use cases / problems that the approach is going to tackle. > > Can you please enhance the document and describe the use cases and what > information those need? > > Technically speaking (from the PR) it's nice to know that e.g. a table > has been changed, but I think that the information is incomplete, > because important attributes like realm, catalog, table identifier and > actor are missing. > > I'm also curious how the approach is intended to be extensible and > backwards compatible when adding new features (generic tables, policies, > etc). > > Since we're talking about event payload here, I think it's necessary to > give users a direction / proposal about which attributes must/may be > serialized in which way to be "future proof". > > Robert > > > On 27.02.25 00:09, Andrew Guterman wrote: > > Just opened a PR https://github.com/apache/polaris/pull/922 > > > > Best, > > Andrew > > > > On Thu, Jan 30, 2025 at 12:24 PM Andrew Guterman < > andrew.guterm...@gmail.com> > > wrote: > > > >> Hi all, > >> > >> Apologies for the delay. > >> > >> Here's my doc > >> < > https://docs.google.com/document/d/1sJiFKeMlPVlqRUj8Rv4YufMMrfCq_3ZFtDuNv_8eOQ0/edit?usp=sharing > > > >> for this along with 2 prototypes: one using Jakarta Events and the other > >> using a custom interface: > >> > >> Please leave comments directly on the doc or reply to this thread. > >> > >> Best, > >> Andrew > >> > >> On Fri, Jan 24, 2025 at 9:59 AM Andrew Guterman < > >> andrew.guterm...@gmail.com> wrote: > >> > >>> I've got a draft in progress and am hoping to share it next week to > >>> collect feedback. > >>> > >>> Best, > >>> Andrew > >>> > >>> On Tue, Jan 21, 2025 at 6:01 PM Yufei Gu <flyrain...@gmail.com> wrote: > >>> > >>>> Quakus runtime(PR469) has been merged. Do we plan to proceed with > >>>> this proposal? Is there any design doc we can refer to? > >>>> > >>>> Yufei > >>>> > >>>> > >>>> On Tue, Jan 7, 2025 at 3:10 PM Andrew Guterman < > >>>> andrew.guterm...@gmail.com> > >>>> wrote: > >>>> > >>>>> Happy new year everyone. > >>>>> > >>>>> I'm still interested in this but waiting for the migration to Quarkus > >>>> to be > >>>>> fully done before proposing anything concrete, as I'd like to see how > >>>> much > >>>>> of this will already be possible. > >>>>> > >>>>> Best, > >>>>> Andrew > >>>>> > >>>>> On Tue, Dec 17, 2024 at 12:23 AM Robert Stupp <sn...@snazy.de> > wrote: > >>>>> > >>>>>> On 14.12.24 11:11, Alex Dutra wrote: > >>>>>>> ServiceLoader > >>>>>>> works, but all the implementations you intend to use must be > >>>> present at > >>>>>>> build time. > >>>>>> Correct (my previous email was wrong wrt to class loading). > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Robert Stupp > >>>>>> @snazy > >>>>>> > >>>>>> > -- > Robert Stupp > @snazy > >
