jackye1995 commented on code in PR #6598:
URL: https://github.com/apache/iceberg/pull/6598#discussion_r1072532309
##########
api/src/main/java/org/apache/iceberg/view/SQLViewRepresentation.java:
##########
@@ -36,17 +38,21 @@ default Type type() {
String dialect();
/** The default catalog when the view is created. */
+ @Nullable
String defaultCatalog();
/** The default namespace when the view is created. */
+ @Nullable
Namespace defaultNamespace();
- /** The query output schema at version create time, without aliases. */
- Schema schema();
+ /** The query output schema id at version create time */
+ int schemaId();
Review Comment:
I see. After taking a deeper look, there are multiple places that we have
`schemaId()` as a part of the API model, such as in `Snapshot`.
I was using the case of `PartitionSpec` to argue that we should stick with
using `schema()`, but it was because there is a process of binding to a schema,
and the serialized version of partition spec is unbounded.
So the question here is not which one is more convenient to implement
parser, but does a view representation needs to bind to a schema at runtime, or
only have a static schema. I think the answer is that it is static, as
described as "ID of the view’s schema when the version was created". So from
that perspective, I agree `schemaId()` seems like a better choice so we don't
need to cross reference existing schemas to make the parser work.
Any thoughts? @amogh-jahagirdar @nastra
--
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: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
