stevenzwu commented on code in PR #11041: URL: https://github.com/apache/iceberg/pull/11041#discussion_r3003387100
########## format/view-spec.md: ########## @@ -160,7 +178,122 @@ Each entry in `version-log` is a struct with the following fields: | _required_ | `timestamp-ms` | Timestamp when the view's `current-version-id` was updated (ms from epoch) | | _required_ | `version-id` | ID that `current-version-id` was set to | -## Appendix A: An Example +#### Storage Table Identifier + +The table identifier for the storage table that stores the precomputed results. + +| Requirement | Field name | Description | +|-------------|----------------|-------------| +| _required_ | `namespace` | A list of strings for namespace levels | +| _required_ | `name` | A string specifying the name of the table | + Review Comment: This field separates logical view (current) with materialized view. MV has this extra field that establishes the connection. Otherwise, how would a reader know if it is a logical view or a MV? Whether the storage table should be exposed in the REST catalog is out of the scope of the MV spec. catalog can choose to skip storage tables for list tables call for consumers. MV producer would still need to be able to load and update the storage table in the catalog. There is this problem of number of round trips for loading view or MV in REST spec * loading a logical view requires 2 round trips: (1) load table - failed (2) load view * load a MV requires 3 round trips with current REST spec: (1) load table -failed (2) load view (3) load storage table I am working on a proposal of universal load endpoint for relational objects: table, view, materialized view. One round trip should be able to load all 3 types of relational objects. I probably can share next week. -- 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]
