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 very welcome and extremely useful.
On 12.06.25 18:39, Eric Maynard wrote:
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 events through the REST service. We already have code in Polaris
emitting the events.
--EM
On Thu, Jun 12, 2025 at 8:35 AM Jean-Baptiste Onofré <j...@nanthrax.net>
wrote:
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, especially about Actor object, so
I would expect some change on the proposal).
Regards
JB
On Wed, Jun 4, 2025 at 7:18 AM Adnan Hemani
<adnan.hem...@snowflake.com.invalid> wrote:
Hi all,
Wanted to start this thread on getting community feedback for the schema
of a new `events` table, as described by my Iceberg Events API
implementation thread <
https://lists.apache.org/thread/nfp40hmwryybznxtgffvy4c5l5kk19ho>.
Schema can be found on this Google Doc - please feel free to comment
directly on the document and we can discuss in the comments section as
well:
https://docs.google.com/document/d/1AxaXy-DXE2g6rmFktA2foDI7k2zIjFzTKmI5mZnUjOs/edit?usp=sharing
Best,
Adnan Hemani
--
Robert Stupp
@snazy
