[
https://issues.apache.org/jira/browse/CALCITE-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17144607#comment-17144607
]
Danny Chen commented on CALCITE-4085:
-------------------------------------
Thanks [~dwysakowicz] ~
> My end goal is to be able to have a nullable record with not null fields.
> E.g. USER(id NOT NULL) <NULLABLE>.
Can adding record nullability attributes in RelDataTypeFactory#Builder [1]
solve your problem ? When you need such data type, use it to construct.
> I want the int to be NOT NULL and be translated to int. Calcite will convert
> it to NULLABLE because of the logic in [1].
I still think the nullability propagation in type factory is correct. Based on
the SQL standard and the fact that:
for expression "[A].[B]", if [A] is nullable then [A].[B] should also be
nullable.
The changes in AliasNamespace makes the TableFunctionTest#testTableFunction
fail is because:
- The row type of the table function GenerateStrings is derived from the
Smalls#generateStrings(Integer) which is actually solid: (JavaType(int) not
null, JavaType(String))
- When you made the change in AliasNamespace, the nested <int> was changed to
<Integer> but the row type of the function is still original, so the validation
and sql-to-rel conversion have un-synced row type and error throws.
This TableFunctionTest#testTableFunction and JavaType demo makes to prefer
believing that, the POJO type inference can behave similarly with the JavaType,
that is, when we encounter a POJO, we can have a specific row type derivation
logic just like what the JavaType does(e.g. How the IntString derive to be a
RelDataType).
That is to say, we should not invoke the type factory
#createTypeWithNullability for non builtin sql type. For example, the POJO
derives the row type by itself.
We do need a way to create such a type, such as in [1]. I'm also +1 for the fix
in SqlSotOperator, SqlItemOperator, the logic in AliasNamespace should be fixed
but it should exclude the JavaType which has its own nullability inference.
[1]
https://github.com/apache/calcite/blob/0769a8b31cbbeb5bca66ade30cf3710523da4aaa/core/src/main/java/org/apache/calcite/rel/type/RelDataTypeFactory.java#L518
> Improve nullability support for fields of structured type
> ---------------------------------------------------------
>
> Key: CALCITE-4085
> URL: https://issues.apache.org/jira/browse/CALCITE-4085
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Dawid Wysakowicz
> Assignee: Dawid Wysakowicz
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As discussed in
> https://lists.apache.org/thread.html/r602ac95fff23dd1ef974fb396df7be061ab861384ec42f5c57ce0bc2%40%3Cdev.calcite.apache.org%3E
> I would like to change the way a type of a field of a record is derived at
> couple of locations. This helps frameworks such as Apache Flink to build
> support for nullable records with not null fields.
> I suggest to change:
> * SqlDotOperator#deriveType
> * SqlItemOperator#inferReturnType
> * AliasNamespace#validateImpl
> * RexBuilder#makeFieldAccessInternal
> * SqlValidatorImpl.DeriveTypeVisitor#visit(SqlIdentifier)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
