Hey all,
First of all, sorry I have not read the entire thread. I just wanted to
make sure you take this one case into consideration.
As far as I know, we map java classes to SQL ROWs? E.g. it is possible to
have a POJO as a parameter to a UDF.
*class MyUDF {*
* eval(MyPojo a)*
*}*
*class
Hi Timo,
Thanks for your valuable feedback.
How about we work together on this topic and create a FLIP for this? We
> need more examples in a unified document. Currently, the proposal is split
> across multiple Flink and Calcite JIRA issues and a ML discussion.
That sounds like a great idea. A
Hi Jane,
thanks for the heavy investigation and extensive summaries. I'm sorry
that I ignored this discussion for too long but would like to help in
shaping a sustainable long-term solution.
I fear that changing:
- RowType#copy()
- RowType's constructor
- FieldsDataType#nullable()
will not
Thanks Shengkai and Xuyang.
@Shengkai
I have one question: Is the influence only limited to the RowType? Does the
> Map or Array type have the same problems?
>
I think the issue is exclusive to RowType. You may want to review
CALCITE-2464[1] for more details.
[1]
Hi, Jane, thanks for driving this.
IMO, it is important to keep same consistent semantics between table api and
sql, not only for maintenance, but also for user experience. But for users, the
impact of this modification is a bit large. Is it possible to consider
introducing a deprecated
Thanks for Jane and Sergey's proposal!
+1 to correct the Table API behavior.
I have one question: Is the influence only limited to the RowType? Does the
Map or Array type have the same problems?
Best,
Shengkai
[DISCUSS][FLINK-31830] Align the Nullability Handling of ROW between SQL
and TableA
Dear devs,
Several issues [1][2][3] have been identified regarding the inconsistent
treatment of ROW type nullability between SQL and TableAPI. However,
addressing these discrepancies might necessitate updates to the public API.
Therefore, I'm initiating this discussion to engage the community in
