bennychow commented on code in PR #11041: URL: https://github.com/apache/iceberg/pull/11041#discussion_r2809831576
########## format/view-spec.md: ########## @@ -82,9 +97,12 @@ Each version in `versions` is a struct with the following fields: | _required_ | `representations` | A list of [representations](#representations) for the view definition | | _optional_ | `default-catalog` | Catalog name to use when a reference in the SELECT does not contain a catalog | | _required_ | `default-namespace` | Namespace to use when a reference in the SELECT is a single identifier | +| _optional_ | `storage-table` | A [storage table identifier](#storage-table-identifier) of the storage table | Review Comment: > Otherwise you won't be able to store configuration options like partitioning, sorting, .. The storage table configuration isn't the source of truth for the MV configuration. This configuration is engine specific and an engine may use view properties or something completely external. > seems natural for the CREATE MATERIALIZED VIEW DDL to create the view and storage table objects together in the catalog. I don't think the spec should require creating the objects together. Imagine this sequence of events: 1. User creates logical view version 1 2. User builds materialization and adds storage table to view version 2 3. User changes view SQL and view schema, removes storage table and commits view version 3 4. User builds new materialization and adds new storage table to view version 4 Basically, I don't see a need to couple the view with the same storage table. Another reason to not couple: For full refresh, the producer can decide whether its more efficient to truncate and rebuild the existing storage table or to create a new storage table and commit that with a new view version. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
