This is the public link: https://www.youtube.com/watch?v=JSN9T20eAuU
-Jack On Tue, Jul 16, 2024 at 7:38 PM Manu Zhang <owenzhang1...@gmail.com> wrote: > Hi Ajantha, > > It looks the catalog sync link is not publicly accessible. Can you check? > > Thanks, > Manu > > On Wed, Jul 17, 2024 at 12:42 AM Ajantha Bhat <ajanthab...@gmail.com> > wrote: > >> We have discussed this yesterday in the catalog sync from *44:00 to >> 1:03:36* >> >> https://drive.google.com/file/d/1SMOlxus5C92FvW9T4LOXy8Ue_9cmPLyX/view?usp=sharing&t=2643 >> >> IIRC, the conclusion was that each catalog may handle namespaces >> differently, with some supporting multi-level namespaces and others not. >> Iceberg does not intend to standardize this behavior, so it is up to each >> catalog to update their documentation regarding their specific behavior. >> >> - Ajantha >> >> >> On Tue, Jul 16, 2024 at 3:12 PM Jean-Baptiste Onofré <j...@nanthrax.net> >> wrote: >> >>> Hi >>> >>> As namespace is not part of the spec, each REST server implementation >>> can use a different logic from another one. >>> The TCK will be able to verify the most abstract operations on >>> namespace (common denominator on namespace behavior). >>> >>> Regards >>> JB >>> >>> On Tue, Jul 16, 2024 at 11:11 AM Yong Zhang <zhangyong1025...@gmail.com> >>> wrote: >>> > >>> > It seems TCK will make sure the logic of the REST is consistent. So in >>> > the future iceberg will make all things align. >>> > >>> > We can merge the current PR to avoid a burden on the user. WDYT? >>> > >>> > Thanks! >>> > Yong >>> > >>> > On Thu, 11 Jul 2024 at 01:04, Ajantha Bhat <ajanthab...@gmail.com> >>> wrote: >>> >> >>> >> Thanks for initiating this discussion. >>> >> >>> >> I suggested moving it to the mailing list because the javadoc of >>> SupportsNamespaces and the REST API spec don't clearly define how to handle >>> missing parent namespaces. >>> >> >>> >> I'm generally +1 of the idea to automatically create missing >>> namespaces now, as it reduces the burden on the user. However, I believe >>> this approach should be standardized and adopted by all catalogs that >>> support multi-level namespaces to avoid confusion. >>> >> That is we need to update the java doc and REST API spec descriptions >>> for this behavior once we have consensus. >>> >> >>> >> - Ajantha >>> >> >>> >> On Wed, Jul 10, 2024 at 7:44 PM Renjie Liu <liurenjie2...@gmail.com> >>> wrote: >>> >>> >>> >>> Hi, Yong: >>> >>> >>> >>> Thanks for reporting this. >>> >>> >>> >>>> Do you think iceberg needs to standardize the REST spec to make >>> sure the >>> >>>> logic is the same for using the SupportsNamespace interface? >>> >>> >>> >>> >>> >>> Yes, I think it's valuable. I remember @Jean-Baptiste Onofré had a >>> proposal for TCK of rest catalog, and this case shows that TCK has a lot of >>> merit. >>> >>> >>> >>> On Wed, Jul 10, 2024 at 5:47 PM Yong Zhang < >>> zhangyong1025...@gmail.com> wrote: >>> >>>> >>> >>>> Hi all, >>> >>>> >>> >>>> When I was using the SupportsNamespaces to do the namespace >>> >>>> create and exists check with other catalog services that implement >>> >>>> the Iceberg REST API, I found it has different results with >>> different >>> >>>> catalog services. Iceberg has provided a standard API to do the >>> >>>> namespace operations, but seems iceberg does not have a standard >>> >>>> spec on the REST API implementation. That makes the other catalog >>> >>>> services implement differently and then breaks the SupportsNamespace >>> >>>> interface usage. >>> >>>> >>> >>>> Do you think iceberg needs to standardize the REST spec to make >>> sure the >>> >>>> logic is the same for using the SupportsNamespace interface? >>> >>>> Otherwise, the SupportsNamespace interface is meaningless because >>> the client >>> >>>> needs to handle different logic to create a namespace or other >>> operations >>> >>>> when using different catalog. >>> >>>> >>> >>>> For example, Nessie doesn't support auto-creating parent namespace: >>> >>>> https://github.com/apache/iceberg/pull/10630 >>> >>>> But the JDBC catalog supports it. >>> >>>> >>> >>>> Thanks. >>> >>>> Yong >>> >>>> >>> >>
