wmoustafa commented on code in PR #7500: URL: https://github.com/apache/iceberg/pull/7500#discussion_r1190610270
########## format/view-spec.md: ########## @@ -98,7 +98,11 @@ View definitions can be represented in multiple ways. Representations are docume A view version can have more than one representation. All representations for a version must express the same underlying definition. Engines are free to choose the representation to use. -Each representation is an object with at least one common field, `type`, that is one of the following: +View versions are immutable. Once a version is created, it cannot be changed. This means that representations for a version cannot be changed. If a view definition changes (or new representations are to be added), a new version must be created. + +A representation is identified by its `type` and `dialect`. A view version can have multiple representations (i.e., different `type` and `dialect` combinations), but at most have one representation for a given `type` and `dialect` pair. Review Comment: @rdblue could you take another look? What I did: * Avoided giving the impression that a type must have more than one dialect. (I think it was the case already before this version, but hopefully this one makes it clearer, especially after removing the `trino`/`spark` example, which is specific to `SQL`). * Said that representation is uniquely identified by the `type` + `dialect` pair. In the future, dialect-less types can have a dialect whose value can only be `N/A`, `None`, `""` or something of that sort. The field is required anyways, so we will have to specify one of those values. -- 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]
