> In general, we find fewer, more focused proposals allow for better
discussion and faster resolution.
Let us have a milestone called "REST catalog v2 spec" (similar to
https://github.com/apache/iceberg/milestone/42)
and keep the multiple smaller proposals organized under that.
- Ajantha
On Thu,
Hi everyone,
Me and a few colleagues at AWS would like to discuss a new proposal for
supporting securable objects in the Iceberg REST catalog spec.
Here is our proposal in Google doc:
https://docs.google.com/document/d/1KmIDbPuN6IYF0nWs9ostXIB9F4b8iH3zZO0hjgs1lm4/edit
And here is the correspondi
Hi everyone,
We're continuing to do monthly community meetups in the Seattle area!
Details are below:
Come meet folks working with Apache Iceberg and Open Table Formats and
learn about new developments in the space. Also, join #meetup-seattle slack
channel for updates on future events.
We will b
Hi Steven,
There are constraints about Spark cherrypick_snapshot and publish_changes
procedure https://iceberg.apache.org/docs/nightly/spark-procedures/#output_3
* for cherrypick_snapshot operation, it says "Only append and dynamic
overwrite snapshots can be cherry-picked.".
* for publish_changes
Pucheng,
I am not sure about others. At least I had some hard time understanding
what the problem/proposal is. What is "cherrypick static partition
overwrite"?
Thanks,
Steven
On Thu, May 30, 2024 at 11:59 AM Pucheng Yang
wrote:
> Hi community,
>
> I would like to follow up on this proposal and
Hi community,
I would like to follow up on this proposal and would like to check if
anyone has concerns about the proposed implementation from a high level
perspective?
Thank you very much
Best,
Pucheng
On Tue, May 28, 2024 at 9:02 PM Pucheng Yang wrote:
> Hi community,
>
> My client is looki
Thanks JB,
I do feel like the discussion around OAuth2, SigV4, etc. is a big enough
topic that we wouldn't want to bundle it with other proposed changes. I
think the discussion around both what is included in the spec and what the
reference implementations will be for each of these protocols will
Hi Jack,
Here's my comments:
1. I don't think we should remove the oauth2 endpoint directly like
this. I would first deprecate the endpoint and plan the removal in the
spec v2.
4. I agree, and it has to be pluggable.
I updated the REST Spec v2 proposal including first steps on v1:
https://docs.g
