github-actions[bot] commented on code in PR #68128:
URL: https://github.com/apache/doris/pull/68128#discussion_r4065209863
##########
fe/fe-connector/fe-connector-iceberg/src/main/java/org/apache/doris/connector/iceberg/IcebergConnectorTransaction.java:
##########
@@ -922,6 +918,28 @@ private Expression buildPartitionFilter(Map<String,
String> staticPartitions, Pa
return result;
}
+ /**
+ * {@code sourceCol = value} for one identity partition key, or the unary
predicate the value demands.
+ *
+ * <p>A NaN cannot be an iceberg literal at all — {@code Literals.from}
throws "Cannot create expression
+ * literal from NaN", and iceberg models it only through {@code
isNaN}/{@code notNaN}. Meanwhile
+ * {@link IcebergPartitionUtils#parsePartitionValueFromString}
deliberately parses Doris's {@code nan}
+ * spelling into {@link Double#NaN}, so a FLOAT/DOUBLE identity partition
holding NaN used to abort the
+ * whole commit ("Failed to commit iceberg transaction: Cannot create
expression literal from NaN") on
+ * both paths that build this predicate: DELETE/UPDATE/MERGE conflict
detection and
+ * {@code INSERT OVERWRITE ... PARTITION(d='nan')}.
+ */
+ private static Expression identityPartitionPredicate(String sourceColName,
Object value) {
+ if (value == null) {
+ return Expressions.isNull(sourceColName);
+ }
+ if ((value instanceof Double || value instanceof Float)
+ && Double.isNaN(((Number) value).doubleValue())) {
+ return Expressions.isNaN(sourceColName);
Review Comment:
[P1] Keep the full query domain in conflict validation
`applyConflictDetectionFilter` later ANDs this touched-partition predicate
with the row-level write constraint. For `DELETE ... WHERE d > 5` on an
identity-partitioned DOUBLE table, a base delete fragment from the NaN
partition now yields `(d > 5 OR isNaN(d)) AND isNaN(d)`. If another transaction
appends `d=10` after `beginWrite`, that file matches the DELETE but is outside
`validateNoConflictingDataFiles`, so the default serializable commit can
succeed without detecting the conflict. The signed-zero fix has the same gap
when only one physical zero partition was touched. The new test has neither
`applyWriteConstraint` nor a concurrent append. Please use the query filter
alone when present (or only intersect a partition projection proven to cover
it) and add those concurrent cases.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
