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