wmoustafa commented on code in PR #11041: URL: https://github.com/apache/iceberg/pull/11041#discussion_r3033423397
########## 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 | When `default-catalog` is `null` or not set, the catalog in which the view is stored must be used as the default catalog. +When `storage-table` is `null` or not set, the entity is a common view, otherwise it is a materialized view. The storage table must be in the same catalog as the materialized view. Review Comment: Thread discussing same type of problem with child table identifiers: https://github.com/apache/iceberg/pull/11041#discussion_r3033212803. This thread would be simplified as well. ########## 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 | When `default-catalog` is `null` or not set, the catalog in which the view is stored must be used as the default catalog. +When `storage-table` is `null` or not set, the entity is a common view, otherwise it is a materialized view. The storage table must be in the same catalog as the materialized view. Review Comment: @stevenzwu We did have cross-catalog child tables at LinkedIn, so this is a pattern I've seen in practice. That said, I agree it's cleaner to avoid it. Constraining child tables to the same catalog as the view would significantly simplify the spec, particularly around identifier resolution and freshness checking. I'd be supportive of that constraint. The limitation is small and not worth the complexity it introduces. **Worth noting:** this constraint doesn't prevent querying across data sources. A single catalog can still federate access to BigQuery, Snowflake, or other systems. The catalog is just an alias; same-catalog doesn't mean same-storage. @talatuyarer FYI. -- 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]
