xiangfu0 opened a new pull request, #18926:
URL: https://github.com/apache/pinot/pull/18926

   ## Description
   
   Follow-up cleanup to the UUID logical type introduced in #18869.
   
   `UUID` is a logical type stored as fixed-width 16-byte `BYTES`, so a 
UUID-typed value's stored representation is always `byte[]` (a `java.util.UUID` 
is only a transient compute-time type) — exactly like `TIMESTAMP` values are 
always `long`. The `DataType` value-semantics methods therefore don't need 
UUID-specific branches:
   
   - **`equals` / `hashCode` / `compare`** now share the `BYTES` path. 
`Arrays.equals`, `Arrays.hashCode`, and `ByteArray.compare` (unsigned 
lexicographic) are byte-for-byte equivalent to 
`UuidUtils.equals`/`hashCode`/`compare` on the fixed 16-byte values, so results 
are unchanged.
   - **`toString`** drops the dead `instanceof UUID` sub-check but keeps the 
canonical `8-4-4-4-12` form (raw hex would break round-tripping through 
`convert()`).
   - **`toBytesValue`** is narrowed to `byte[]`/`ByteArray` only; UUID-object 
and canonical-`String` inputs are no longer accepted, matching its Javadoc 
(*"input value should be byte[]"*). No stored-value caller passes those.
   - Removed the now-unused `java.util.UUID` import.
   
   Dispatch stays uniform across the four methods (each enumerates `BYTES` and 
`UUID` explicitly) so a future `BYTES`-stored logical type is not silently 
folded into the byte path.
   
   ## Testing
   
   - `FieldSpecTest` + `UuidUtilsTest` pass (57 tests). The 
equality/hash/compare equivalence is pinned by existing assertions 
(`FieldSpecTest#testUUIDConversions`, 
`UuidUtilsTest#testComparePreservesUnsignedByteOrdering`).
   - `spotless:check`, `checkstyle:check`, `license:check` clean on `pinot-spi`.
   
   ## Backward-compatibility
   
   Behavior-preserving for all valid UUID values. UUID is unreleased 
(introduced in #18869, not in any release tag), so there is no cross-version 
wire/serialization surface affected.


-- 
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]

Reply via email to