Hi all, I meant the registered view in the new catalog uses the `default-catalog` as the old catalog name. Which inturn causes the failure to read the view in Spark. So, the discussion was about catalog names. Should we update it during register view or from a separate procedure. I am in favour of separate procedures.
And thanks Christian for bringing up the java implementation issue with `default-namespace` (another field in the spec). We will check if the new procedure can also fix that in the existing views and new views from Spark can avoid writing like that. - Ajantha On Wed, Jan 7, 2026 at 10:08 PM Christian Thiel <[email protected]> wrote: > > Hi Ajantha, > > I agree with your approach - register should not change the default-namespace. > > When we write the routine in spark, we might want to re-visit the use of > `default-namespace` a bit more thoroughly. While it is a required field in > the spec, Spark sends an empty array as `default-namespace`. This is against > the spec which states that a namespace is a `Reference to one or more levels > of a namespace` - not zero. It also creates cross-language problems, as rust > is following the spec and returns an error when trying to construct a > namespace without 0 elements [1]. > > Best, > Christian > > [1]: > https://github.com/apache/iceberg-rust/blob/7f2dda3a3807e89b162785b4f16d655ca6b84f79/crates/iceberg/src/catalog/mod.rs#L142-L145 > > On Wed, 7 Jan 2026 at 09:04, Ajantha Bhat <[email protected]> wrote: >> >> Hi Everyone, >> >> During implementation of register view, observed that view spec captures >> default namespace. So, once the views are registered from one catalog to >> another, Spark cannot read that view as it still points to the old >> catalog-name as the default namespace. This problem is specific to spark >> integration and we had similar concerns during the spec design. >> >> I would like to keep the scope of register view limited to just registering >> the existing view to the catalog, similar to register table. For updating or >> fixing the catalog name, we can provide a separate Spark procedure. >> >> I don’t think the register view itself should update the catalog name, >> because that would mean creating a new metadata file and a new version, >> which is not really a register operation. >> >> Any thoughts on this? >> >> - Ajantha >> >> On Wed, Dec 17, 2025 at 9:11 PM Ajantha Bhat <[email protected]> wrote: >>> >>> Here are the PRs: >>> >>> - API,Core: Support registerView for view catalog #14868 >>> - SPEC: Add REST endpoint for registering views #14869 >>> - REST: Implement register view for REST catalog #14870 >>> >>> I will open a separate vote thread for spec change, once the spec PR is >>> reviewed. >>> >>> - Ajantha >>> >>> On Tue, Dec 16, 2025 at 8:52 AM Kevin Liu <[email protected]> wrote: >>>> >>>> Thanks for the pointer! I missed the Spark page. Tried it out locally and >>>> wrote some view metadata files. >>>> Looking forward to the PR. >>>> >>>> Best, >>>> Kevin Liu >>>> >>>> >>>> On Mon, Dec 15, 2025 at 6:28 PM Ajantha Bhat <[email protected]> wrote: >>>>>> >>>>>> are there any engines currently supporting the view spec? Based on my >>>>>> search, I’m not aware of any. >>>>> >>>>> Hi Kevin, could you clarify what you meant here? The Iceberg View Spec >>>>> has already been officially approved, and the IRC spec is approved as >>>>> well. Both Spark (see docs) and Dremio already support it. Other engine >>>>> users can comment more on their integration. >>>>> >>>>> >>>>>> It might make sense to prioritize view spec adoption first, so we have >>>>>> more view metadata JSONs available before adding additional view-related >>>>>> functionality to the IRC spec. >>>>> >>>>> >>>>> While broader adoption of the view spec would definitely help, I don’t >>>>> think we should delay adding register view support. Since format version >>>>> 1 is already standardized and in use, we can always introduce further >>>>> improvements in format version 2. >>>>> >>>>> - Ajantha >>>>> >>>>> >>>>> On Mon, Dec 15, 2025 at 9:32 PM Kevin Liu <[email protected]> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Following up on this, are there any engines currently supporting the >>>>>> view spec? Based on my search, I’m not aware of any. >>>>>> It might make sense to prioritize view spec adoption first, so we have >>>>>> more view metadata JSONs available before adding additional view-related >>>>>> functionality to the IRC spec. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Best regards, >>>>>> Kevin Liu >>>>>> >>>>>> >>>>>> On Tue, Dec 9, 2025 at 9:57 PM Ajantha Bhat <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> Thanks everyone. >>>>>>> >>>>>>> As there are no additional comments on the proposed solution, I’ll move >>>>>>> forward with the implementation and share the corresponding PRs when >>>>>>> they’re ready. >>>>>>> >>>>>>> - Ajantha >>>>>>> >>>>>>> On Tue, Dec 2, 2025 at 10:42 PM Kevin Liu <[email protected]> wrote: >>>>>>>> >>>>>>>> That's a good point, Gabor. Catalog servers advertise view support >>>>>>>> through the getConfig (v1/config) response. So a dedicated register >>>>>>>> view endpoint is more explicit. This way also provides separate authz >>>>>>>> for registerView, as Ajantha mentioned. I like this method. >>>>>>>> >>>>>>>> Just to recap on the above. The 2 other ideas are >>>>>>>> - overload the /register endpoint to support view, using an optional >>>>>>>> header param (i.e. view=true) >>>>>>>> - overload the /register endpoint to support view; try as table first, >>>>>>>> then fallback to view (similar to the loadTable behavior) >>>>>>>> >>>>>>>> Best, >>>>>>>> Kevin Liu >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Dec 2, 2025 at 6:56 AM Gábor Kaszab <[email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hey All, >>>>>>>>> >>>>>>>>> +1 for the improvement in general. >>>>>>>>> Also, I think it makes sense to make a distinction between table >>>>>>>>> endpoints and view endpoints instead of making the register endpoint >>>>>>>>> more general. The server could articulate explicitly if such a >>>>>>>>> register view endpoint is supported or not when returning the list of >>>>>>>>> supported endpoints. If we change the register endpoint to serve >>>>>>>>> both, we won't be able to decide simply by looking at the list of >>>>>>>>> endpoints if the server is able to register views or not. >>>>>>>>> So +1 for a new endpoint. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Gabor >>>>>>>>> >>>>>>>>> Jean-Baptiste Onofré <[email protected]> ezt írta (időpont: 2025. >>>>>>>>> dec. 2., K, 15:09): >>>>>>>>>> >>>>>>>>>> Hi Tobias, >>>>>>>>>> >>>>>>>>>> If it is an optional field in the request body, that would also be >>>>>>>>>> acceptable to me, provided it does not break existing clients. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> JB >>>>>>>>>> >>>>>>>>>> On Tue, Dec 2, 2025 at 11:33 AM Tobias <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> What speaks against making /register first try the provided >>>>>>>>>>> metadata as a table and then as a view before rejecting as invalid? >>>>>>>>>>> >>>>>>>>>>> @JB, why would you prefer a header param over an optional field >>>>>>>>>>> `type` in the request? >>>>>>>>>>> >>>>>>>>>>> Kind regards, >>>>>>>>>>> Tobias >>>>>>>>>>> >>>>>>>>>>> Am Di., 2. Dez. 2025 um 07:45 Uhr schrieb Jean-Baptiste Onofré >>>>>>>>>>> <[email protected]>: >>>>>>>>>>>> >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> I agree that registerView makes sense. >>>>>>>>>>>> >>>>>>>>>>>> Regarding the /register endpoint in the IRC spec, maybe we can use >>>>>>>>>>>> a header param (optional) when we want to register a view >>>>>>>>>>>> (view=true for instance). >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> JB >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Dec 2, 2025 at 5:12 AM Kevin Liu <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Ajantha, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for bringing this up. I think it's a good idea to be able >>>>>>>>>>>>> to register views, and by extension, to replicate from one >>>>>>>>>>>>> catalog to another. >>>>>>>>>>>>> >>>>>>>>>>>>> The `registerView` function makes sense to me. The IRC spec, >>>>>>>>>>>>> however, might be a bit more complicated. The "register" endpoint >>>>>>>>>>>>> (`/v1/{prefix}/namespaces/{namespace}/register`) [1] is currently >>>>>>>>>>>>> used to register tables only. We could either extend this >>>>>>>>>>>>> endpoint to support views or create a separate "registerView" >>>>>>>>>>>>> endpoint. >>>>>>>>>>>>> >>>>>>>>>>>>> Would love to hear what others think. >>>>>>>>>>>>> >>>>>>>>>>>>> Best, >>>>>>>>>>>>> Kevin Liu >>>>>>>>>>>>> >>>>>>>>>>>>> [1] >>>>>>>>>>>>> https://github.com/apache/iceberg/blob/b35c7ec1b03e3897da68960cd556d635b2f5ae54/open-api/rest-catalog-open-api.yaml#L868 >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Nov 25, 2025 at 2:28 AM Ajantha Bhat >>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi everyone, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Currently, catalogs provide a registerTable function that allows >>>>>>>>>>>>>> registering an existing table with a catalog if it does not >>>>>>>>>>>>>> already exist. This is particularly useful for migrating Iceberg >>>>>>>>>>>>>> tables between catalogs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We have users who are in the process of migrating from one >>>>>>>>>>>>>> catalog to another. While migrating tables works well, migrating >>>>>>>>>>>>>> views remains challenging. One option is to simply recreate the >>>>>>>>>>>>>> views, since view creation is a lightweight operation. However, >>>>>>>>>>>>>> this approach has two main drawbacks: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Recreating a view loses its version history and original >>>>>>>>>>>>>> metadata. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Some catalogs may not allow recreating a view if a view with the >>>>>>>>>>>>>> same name already exists in the target location. >>>>>>>>>>>>>> >>>>>>>>>>>>>> To address this, I propose adding a registerView functionality >>>>>>>>>>>>>> for completeness. This would enable users to register existing >>>>>>>>>>>>>> views with a catalog, similar to how we register existing tables >>>>>>>>>>>>>> today. >>>>>>>>>>>>>> >>>>>>>>>>>>>> As a follow-up, I can open a PR to implement: >>>>>>>>>>>>>> >>>>>>>>>>>>>> registerView(TableIdentifier identifier, String >>>>>>>>>>>>>> metadataFileLocation) in ViewCatalog >>>>>>>>>>>>>> >>>>>>>>>>>>>> Corresponding updates to the Iceberg REST catalog spec >>>>>>>>>>>>>> >>>>>>>>>>>>>> Necessary API additions >>>>>>>>>>>>>> >>>>>>>>>>>>>> Would love to hear your thoughts and feedback on this proposal. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Ajantha
