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