The issue I see is that the proposal is not finalized. And without that
we do not know the keys and most importantly the query patterns. Without
that information it's not possible to design an efficient data model.
As mentioned during the community sync, a working prototype in a
draft-PR is ve
The Polaris event listener framework is not necessarily 1:1 to the Iceberg
Events API -- IIRC, it actually predated the Iceberg Events API proposal. I
think the pieces of code that just involve persisting Polaris events
somewhere may not need to block on the Iceberg API changes to retrieve
Iceberg
Hi Adnan
Nice document ! I will do a full pass and comment.
I think it's great to have a draft PR as "implementation ref" for the
Iceberg proposal. I would just suggest keeping the PR as draft,
waiting for a consensus on the Iceberg Events API (during the last
catalog meeting, we had discussions,
Hi,
If I understand correctly, this effort is still in the "proposal state"
in Iceberg (the PR itself is still a draft). This means that nothing is
set "in stone" yet. Things can still change fundamentally, the proposal
can even be rejected.
IMHO we should wait adding code to Polaris until t
Hi Yufei,
Thanks for the comments, I’ve addressed all of them. The second half of the
document briefly outlines how we will transform the Polaris internal
persistence events into Iceberg Events to return back as part of the Iceberg
Event Endpoint.
Best,
Adnan Hemani
> On Jun 8, 2025, at 4:02
Thanks Adnan for driving this. Left comments in the google doc.
The current schema proposal is good if this is only for Polaris internal
persistence. It'd also be a good idea to make sure it is
compatible with the Iceberg Event Endpoints [1][2].
[1]
https://docs.google.com/document/d/1WtIsNGVX75-
