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 > <https://iceberg.apache.org/docs/nightly/spark-ddl/#iceberg-views-in-spark>) > 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 >>>>>>>>>> >>>>>>>>>
