Hi Yufei, I think keeping the non-catalog option available makes sense, and adding an extra check for this non-standard approach doesn’t seem like a big issue to me. That said, the community consensus appears to be gradually shifting away from the non-catalog approach. If you look at the REST planning mode discussion [1], we’re even considering Iceberg tables without any metadata stored on the underlying storage. It might be worth defining a consistent, general approach for decisions like these.
Thanks, Peter [1] - [DISCUSS] REST: Scan Planning mode - https://lists.apache.org/thread/z1g4y8b4ogdrn0jjtjlgg7yjgxdbzpvg Yufei Gu <[email protected]> ezt írta (időpont: 2026. jan. 15., Cs, 0:17): > Peter, > Based on the discussion(sorry, I don't have a link to share) so far, the > community conclusion is that we should always keep the non catalog option > available. In other words, even catalogs are the recommended way to locate > view metadata, non catalog based access remains a supported option. This > gives us flexibility to support different deployment models. > > Yufei > > > On Wed, Jan 14, 2026 at 2:20 AM Péter Váry <[email protected]> > wrote: > >> > For example, when locating the view metadata.json, clients would need >> to check two possible locations, "/location" and "/location/metadata". >> >> Do I understand correctly that users are expected to use the Catalog to >> locate metadata.json? In my opinion they should not rely on filenames to >> locate views.” >> >> Yufei Gu <[email protected]> ezt írta (időpont: 2026. jan. 14., Sze, >> 3:49): >> >>> Thanks Gabor for raising this. The alternative approach is appealing, as >>> it avoids supporting the same behavior through multiple properties. My main >>> concern is potential impact on existing use cases. For example, when >>> locating the view metadata.json, clients would need to check two possible >>> locations, "/location" and "/location/metadata". This may not be a >>> significant issue, since the spec does not mandate the metadata suffix, but >>> it does introduce incompatibility with the existing convention. It would be >>> helpful for others to chime in and share view use cases that rely on the >>> "metadata" suffix today, and POV on whether it's OK to adapt the change. >>> >>> Yufei >>> >>> >>> On Tue, Jan 13, 2026 at 5:23 AM Gábor Kaszab <[email protected]> >>> wrote: >>> >>>> Hey Iceberg Community, >>>> >>>> *TLDR* >>>> I'd like to de-deprecate the 'write.metadata.path' view property >>>> <https://github.com/apache/iceberg/blob/main/core/src/main/java/org/apache/iceberg/view/ViewProperties.java> >>>> and would like to see if there are any objections. >>>> >>>> *Details* >>>> We have use-cases where it's necessary to configure tables and views to >>>> have custom paths for metadata, in particular not to enforce adding the >>>> metadata/ folder under the hood. For both tables and views there is >>>> 'write.metadata.path' property that could achieve this. However, for views >>>> this is deprecated now. >>>> >>>> After talking to Yufei, the reason for this property being deprecated >>>> is that for views this is somewhat duplicated functionality with the >>>> 'location' property seemingly serving the same purpose. There are some >>>> differences though: >>>> - 'location': This gives the root folder of the view and metadata >>>> would be written under 'location'/metadata folder. >>>> - 'write.metadata.path': This has higher precedence over 'location' >>>> and metadata would be written directly into 'write.metadata.path' without >>>> the metadata/ folder. >>>> >>>> An *alternative approach* could be to drop 'write.metadata.path' and >>>> change the behaviour of 'location' to not create a metadata/ folder under >>>> the hood. The view spec doesn't mention explicitly that metadata/ folder is >>>> a requirement, however, it gives an example >>>> <https://iceberg.apache.org/view-spec/#appendix-a-an-example> where it >>>> is present and also mentions that it is there to follow the structure of >>>> the tables. So changing this would be confusing at least, but could be >>>> considered a breaking change too. I wouldn't go this way. >>>> >>>> So long story short, I'd like to keep 'write.metadata.path' for views >>>> despite the similar purpose as 'location', to avoid generating the >>>> metadata/ folder. >>>> >>>> Any feedback is appreciated! >>>> Gabor >>>> >>>
