Thanks for the summary, Yun! It looks good to me.
Cheers,
Dmitri.
On Tue, Mar 4, 2025 at 2:33 PM yun zou wrote:
> Hi All,
>
> Thanks a lot for all the valuable feedback!
>
> Summary for the discussion we had during the offline meeting:
> 1) For the new APIs, we will put it under a new prefix */
Hi Yun,
It looks good to me, thanks !
Regards
JB
On Tue, Mar 4, 2025 at 8:31 PM yun zou wrote:
>
> Hi All,
>
> Thanks a lot for all the valuable feedback!
>
> Summary for the discussion we had during the offline meeting:
> 1) For the new APIs, we will put it under a new prefix */catalog/polaris
Thanks Yun for driving this. +1 on add a prefix "polaris" on new Polaris
native APIs, and keep the existing ones as is.
Yufei
On Tue, Mar 4, 2025 at 11:31 AM yun zou wrote:
> Hi All,
>
> Thanks a lot for all the valuable feedback!
>
> Summary for the discussion we had during the offline meet
Hi All,
Thanks a lot for all the valuable feedback!
Summary for the discussion we had during the offline meeting:
1) For the new APIs, we will put it under a new prefix */catalog/polaris/
to avoid any future conflict with Iceberg and indicate clearly that those
set of APIs are defined by Polaris.
-1 on changing the path for the existing table APIs. People already have
production systems pointing to Polaris endpoints and I don't think there's
a strong reason to force them to migrate. I think adding new prefixes for
new functionality is fine, but adding new features shouldn't break existing
b
WRT to the term "generic", I suspect that it can evolve to a more
generic catalog API, that could also expose functionality for Iceberg
tables + views and isn't limited to "generic tables" (too many different
meanings of "generic" there...). So not a fan of using the term
"generic" in a REST AP
"If Polaris were to add new endpoints under /catalog/v1 and then Iceberg
releases a v2 REST Catalog API what happens to the Polaris-specific
endpoints?"
-- I think that is a great point, I am actually with Dmitri now -- a new
prefix could be beneficial for Polaris API to evolve independently in th
Hi everyone,
Thanks Yun for initiating the discussion and Dmitri for the proposal! I
think a similar question applies to Policy management APIs as well. In
general, we need to figure out how we handle Polaris-native, non-Iceberg
catalog-level APIs.
> * /catalog/v1 - remains supported for Iceberg
The current /catalog/v1 URI prefix encapsulates the Iceberg REST Catalog
API. This API is not owned by Polaris.
If Polaris were to add new endpoints under /catalog/v1 and then Iceberg
releases a v2 REST Catalog API what happens to the Polaris-specific
endpoints? What if Iceberg adds an endpoint th
Hi All,
Thanks all for attending the review today and providing your valuable
feedback, I really appreciate it ! And apologize for the late notice for
the review meeting here.
I think we had a good discussion, and agreed to
1) Move on to provide a new Spark Catalog Plugin and new set of APIs with
d provide the capability for Polaris to manage non-Iceberg
tables, which we call *Generic Table* in Polaris.
Here, we propose a way to manage Generic tables in Polaris, as well as a
new Spark Catalog plugin for Spark to work with Polaris.
Here is a link to the proposal doc: Generic Table Sup
eet: https://meet.google.com/izz-zui
x-fwc\n\nLearn more about Meet at: https://support.google.com/a/users/answe
r/9282720\n\nPlease do not edit this section.\n-::~:~::~:~:~:~:~:~:~:~:~:~:
~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-
LAST-MODIFIED:20250222T013241Z
LOCATION:
SEQUENCE:1
STATUS:C
hould provide the capability for Polaris to manage non-Iceberg
tables, which we call *Generic Table* in Polaris.
Here, we propose a way to manage Generic tables in Polaris, as well as a
new Spark Catalog plugin for Spark to work with Polaris.
Here is a link to the proposal doc: Generic Table Supp
13 matches
Mail list logo
