raminqaf opened a new pull request, #29128:
URL: https://github.com/apache/flink/pull/29128
## What is the purpose of the change
This makes the `UUID` type usable as a key: in comparisons (`=`, `<>`, `<`,
`>`, `<=`, `>=`), `ORDER BY`, `GROUP BY`, `DISTINCT` and join conditions. It is
a subtask of FLIP-604.
`UUID` is stored internally as its 16-byte big-endian encoding, and the type
defines ordering as the unsigned big-endian byte comparison of that encoding.
This is exactly the ordering that Flink's existing binary compare helpers
already implement (`SortUtil.compareBinary` for the sort path and
`SqlFunctionUtils.byteArrayCompare` for the predicate path, both unsigned). The
change therefore routes `UUID` through those existing binary paths at the
code-generation sites that previously threw for it, rather than introducing any
new comparison logic. The unsigned order is consistent with the DataStream
`UuidComparator` introduced with the runtime support.
A predicate such as `WHERE uuid_col = UUID '...'` additionally requires a
`UUID` literal to round-trip between a `RexNode` and an `Expression` when the
planner pushes it into a filterable source. `RexBuilder#makeLiteral` has no
generic `UUID` support, so this also adds a `UUID` case to
`ExpressionConverter` that builds the literal directly.
## Brief change log
- `TypeCheckUtils#isComparable` now treats `UUID` as comparable (this
gates the equality/comparison codegen).
- `GenerateUtils#generateCompare` groups `UUID` with `BINARY`/`VARBINARY`
(`SortUtil.compareBinary`), covering `ORDER BY`, sort-merge joins and
over-window ordering.
- `ScalarOperatorGens#generateComparison` compares `UUID` via
`SqlFunctionUtils.byteArrayCompare`, covering the comparison operators in
`WHERE`/`JOIN`/`HAVING` and the generated record equaliser.
- `SortCodeGenerator` gives `UUID` a fixed 16-byte, fully determining
normalized key (reusing the binary accessors).
- `AggregateUtil#createDistinctKeyType` accepts `UUID`, enabling
`COUNT(DISTINCT uuid)`.
- `ExpressionConverter` builds a `UUID` literal via
`RexBuilder#makeUuidLiteral` so it round-trips through filter push-down.
## Verifying this change
This change added tests and can be verified as follows:
- `SortCodeGeneratorTest`: adds `UUID` to the randomized sort harness,
with `0x00…` / `0x80…` / `0xff…` boundary values that make the unsigned and
signed byte orders disagree.
- `UuidSemanticTest` (streaming): column-vs-column `=` and `<`, plus a `>
UUID '7fff…'` literal filter that exercises the push-down round-trip.
- `UuidBatchSemanticTest` (new, batch): `ORDER BY` (asserted via a
`ROW_NUMBER` rank), `GROUP BY`, `COUNT(DISTINCT)` and a join on a `UUID` key.
## Does this pull request potentially affect one of the following parts:
- Dependencies (does it add or upgrade a dependency): no
- The public API, i.e., is any changed class annotated with
`@Public(Evolving)`: no
- The serializers: no
- The runtime per-record code paths (performance sensitive): yes. `UUID`
reuses the existing unsigned binary comparison and a fixed-length normalized
key; no other type's compare path changes.
- Anything that affects deployment or recovery: JobManager (and its
components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
- The S3 file system connector: no
## Documentation
- Does this pull request introduce a new feature? yes
- If yes, how is the feature documented? Documentation for the `UUID` type
is tracked separately under FLINK-40494.
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes (please specify the tool below)
Generated-by: Claude Code (Opus 4.8)
--
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]
