e that happens in the table such as
>>> create, drop table/namespace.
>>>
>>> 2. Access events: any time user accesses a table, calls list. It
>>> is good to send notification because they can be consumed by the users if
>>> they want to track usage fo
gt;>
>>
>> When this is implemented, could we provide generic hooks and events so
>> that another notification system such as PubSub (on GCP) or Kakfa can be
>> leveraged.
>>
>>
>>
>> I’m happy to join any brainstorming discussion around this topic.
&g
e generic hooks and events so
> that another notification system such as PubSub (on GCP) or Kakfa can be
> leveraged.
>
>
>
> I’m happy to join any brainstorming discussion around this topic.
>
>
>
> Thanks,
>
> Mayur
>
>
>
> *From:* Kyle Bendickson
>
PubSub (on GCP) or Kakfa can be leveraged.
I’m happy to join any brainstorming discussion around this topic.
Thanks,
Mayur
From: Kyle Bendickson
Sent: Wednesday, December 1, 2021 1:23 AM
To: dev@iceberg.apache.org
Subject: Re: Iceberg event notification support
I think this is a great idea, Jack
I think this is a great idea, Jack. Thank you for bringing this up! +1
There have been several people interested in having more observability (for
example for table design patterns akin to how folks might monitor Hive) and
events would be a big win for that and something users could use with a lot
+1 to this effort.
There is value in adding support for Events - general bookkeeping and
helping replay actions in the event of recovery.
At the minimum we should aim to track the following all catalogs:
1. Create actions
2. Alter actions
3. Delete actions
across all tables, properties and namespac
