[
https://issues.apache.org/jira/browse/FLINK-17793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17276151#comment-17276151
]
Jark Wu commented on FLINK-17793:
---------------------------------
Thanks [~twalthr] for the great summary. However, I have some concerns around
the backward-compatibility.
Flink Table/SQL API has been an important API for many downstream projects,
e.g. Iceberg, Hudi, Zeppelin. We have breaked the compatibility of
{{TableColumn}} in the 1.12 version without any documentation, and this was
complained by some Iceberg guys [1]. Therefore, I think we need to take
compatibility very seriously.
Therefore, my thoughts on the proposal:
1) could we not move the public API `table.api.TableColumn`,
`table.api.WatermarkSpec`, `table.api.constraints.UniqueConstraint`? I don't
see much benefit of the package moving.
5) `Schema` doesn't have any getter methods, from my point of view, it's just a
DDL builder. Is there any use cases to expose it on `CatalotBaseTable`?
6) Not sure about this. This sounds like we provide more methods to get
physical row data type, will it be more confusing when and which method to call?
7) If we want to refactor `TableColumn` and `WatermarkSpec`, we should also
keep compatible for at-least one or two versions.
[1]: https://github.com/apache/iceberg/pull/1956#discussion_r546534299
> Replace TableSchema with dedicated CatalogSchema
> ------------------------------------------------
>
> Key: FLINK-17793
> URL: https://issues.apache.org/jira/browse/FLINK-17793
> Project: Flink
> Issue Type: Sub-task
> Components: Table SQL / API
> Reporter: Timo Walther
> Assignee: Timo Walther
> Priority: Major
>
> The {{TableSchema}} is used for representing the schema of catalog table and
> the schema of a {{Table}} object and operation. We should split those
> responsibilities both for a cleaner API and long-term separation of concerns.
> Connectors should work on a CatalogSchema instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
