Hi folks, do we have updates on this? Are we still pursuing it? I saw the PR https://github.com/apache/iceberg/pull/12584/files is in draft state. Could we make it ready to review?
Yufei On Wed, May 28, 2025 at 10:34 AM Christian Thiel <[email protected]> wrote: > Thank you all for the great discussion today! > I have updated the proposal. Key changes are: > > - > > Specify that clients should ignore unknown operation & event types > - > > Specify the `actor` field as part of the `Event` schema as an opaque > string. Remove the `Actor` type. > - Remove the `actors` filter from the `GetEventsRequest`, add an > extendable `custom-filters` object instead (`additionalProperties: true`) > > The diff for the changes since the sync today is available in Github: > https://github.com/apache/iceberg/pull/12584/commits/3de9a7c5d128b1100c38ce688603c94491008d35 > The google doc is also updated, > https://docs.google.com/document/d/1WtIsNGVX75-_MsQIOJhXLAWg6IbplV4-DkLllQEiFT8/edit?usp=sharing > > Looking forward to more feedback, especially regarding custom operations! > > On Tue, 27 May 2025 at 10:15, Christian Thiel <[email protected]> > wrote: > >> Dear all, >> >> I think we have reached mostly consensus here. >> There is one more change since our last discussion: We removed the >> recursive "assumed-by" field of actors in favor or an "actor-chain" list. >> >> If there is any more need for discussion please voice it here on the >> Mailing List or in the Catalog sync tomorrow. I would otherwise start a >> vote. >> >> Best, >> Christian >> >> On Wed, 7 May 2025 at 11:18, Christian Thiel <[email protected]> >> wrote: >> >>> Dear all, >>> >>> I worked the changes discussed in the last catalog sync into the Events >>> proposal [1]. >>> Those include: >>> - Using request-id instead of transaction >>> - A more flexible User (now called Actor) >>> - Custom Operation type >>> >>> The specific diff compared to the last discussion can be best seen in my >>> latest commit in git [2]. >>> It would be good to still comment in Google Docs so that we have >>> everything in one place. >>> >>> Best, >>> Christian >>> >>> [1]: >>> https://docs.google.com/document/d/1WtIsNGVX75-_MsQIOJhXLAWg6IbplV4-DkLllQEiFT8/edit?usp=sharing >>> [2]: >>> https://github.com/apache/iceberg/pull/12584/commits/4d67051e03d5345687566b3900db3af23ce15766 >>> >>> >>> On Wed, 16 Apr 2025 at 14:53, Christian Thiel < >>> [email protected]> wrote: >>> >>>> Dear all, >>>> after the last Catalog sync I updated the proposal. >>>> Changes are in the original proposal Document [1] and the original PR >>>> [2] >>>> >>>> Best, >>>> Christian >>>> >>>> [1] >>>> https://docs.google.com/document/d/1WtIsNGVX75-_MsQIOJhXLAWg6IbplV4-DkLllQEiFT8/edit?usp=sharing >>>> [2] https://github.com/apache/iceberg/pull/12584 >>>> >>>> >>>> On Thu, 20 Mar 2025 at 10:49, Christian Thiel < >>>> [email protected]> wrote: >>>> >>>>> Dear all, >>>>> >>>>> We have recently discussed in the Iceberg Catalog Community Sync [1] >>>>> and the Mailing List [2] different ways on how federation between Catalogs >>>>> could be standardized. >>>>> >>>>> This proposal introduces a /events endpoint to the IRC specification. >>>>> The endpoint provides events of modifications to objects managed by the >>>>> Catalog (tables, namespaces, views), allowing consumers to efficiently >>>>> track metadata changes using persistent offsets for reliable consumption >>>>> and resumability. >>>>> >>>>> Proposal Document: >>>>> https://docs.google.com/document/d/1WtIsNGVX75-_MsQIOJhXLAWg6IbplV4-DkLllQEiFT8/edit?usp=sharing >>>>> >>>>> I am looking forward to your thoughts and hope we find time in next >>>>> week's Catalog sync to discuss this further. >>>>> >>>>> Best >>>>> Christian >>>>> >>>>> [1] Catalog Community Sync Feb. 2025 >>>>> https://www.youtube.com/watch?v=hYcehreE8Nk >>>>> [2] Mailing List, September 2024 - Notifications Endpoint: >>>>> https://lists.apache.org/thread/zcv6qm9ysknrhfpg093qgnrkrolptcht >>>>> >>>>
