Abacn commented on code in PR #38206:
URL: https://github.com/apache/beam/pull/38206#discussion_r3119591113
##########
sdks/java/extensions/sql/src/main/java/org/apache/beam/sdk/extensions/sql/impl/utils/CalciteUtils.java:
##########
@@ -254,6 +261,9 @@ public static Schema.Field toField(String name, RelDataType
calciteType) {
}
public static FieldType toFieldType(RelDataType calciteType) {
+ if (LOGICAL_TYPE_REL_DATA_MAPPING.containsKey(calciteType)) {
+ return LOGICAL_TYPE_REL_DATA_MAPPING.get(calciteType);
+ }
Review Comment:
> In Apache Calcite, RelDataType equality is determined by checking if two
type objects represent the same structure, including nullability, precision,
and scale.
Admittedly the conflict is possible, for example, when two
PassThroughLogicalTypes have identical base type, field names and types,
nullability, etc. Basically we're choosing between (1) losing the outer level
of nested logical types at all---the previous commit; and (2) set to the
compatible top level logical type which---the latest commit. (2) is
preferredand needed to preserve pythonsdk_any logical type in output schema.
The problem here is that RelDataType doesn't provide an interface to add
label or any metadata to it, so we lose the bi-direction mapping of beam
type<->calcite type. The static map try to partly solve it.
Navertheless either choice are better than 2.72.0 which would just fail as
```
dataTypeFactory.createSqlType(toSqlTypeName(fieldType))
```
as `dataTypeFactory.createSqlType('ROW')` creates a ROW type without setting
fields which will crash in latter stage.
That said there is no backward compatibility concern here.
=====
RelDataType.getSqlTypeName() will just be an enum "ROW".
--
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]
