Re: Endpoint prefix name for Generic Table Support in Apache Polaris

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 */

Re: Endpoint prefix name for Generic Table Support in Apache Polaris

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

Re: Endpoint prefix name for Generic Table Support in Apache 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

Re: Endpoint prefix name for Generic Table Support in Apache Polaris

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.

Re: Endpoint prefix name for Generic Table Support in Apache 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

Re: Endpoint prefix name for Generic Table Support in Apache Polaris

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

Re: Endpoint prefix name for Generic Table Support in Apache 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?" -- 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

Re: Endpoint prefix name for Generic Table Support in Apache Polaris

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

Re: Endpoint prefix name for Generic Table Support in Apache Polaris

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

Endpoint prefix name for Generic Table Support in Apache Polaris

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