xiangfu0 commented on code in PR #18872:
URL: https://github.com/apache/pinot/pull/18872#discussion_r3669802317
##########
pinot-core/src/main/java/org/apache/pinot/core/common/DataFetcher.java:
##########
@@ -416,6 +422,23 @@ void readBigDecimalValues(int[] docIds, int length,
BigDecimal[] valueBuffer) {
void readStringValues(int[] docIds, int length, String[] valueBuffer) {
Tracing.activeRecording().setInputDataType(_storedType, _singleValue);
ForwardIndexReaderContext readerContext = getReaderContext();
+ // A UUID column is stored as BYTES, so both paths below would render it
as hex -- the dictionary is a
+ // BytesDictionary whose getStringValue() is toHexString(). Render the
canonical form here, at the only layer
+ // that still knows the column's logical type, so every
getStringValuesSV() caller gets it right.
+ if (_dataType == DataType.UUID) {
Review Comment:
You are right — removed entirely, and I removed the equivalent UUID branches
in `BaseTransformFunction.transformToStringValues{SV,MV}` for the same reason.
I checked your BOOLEAN/TIMESTAMP analogy against the code and it holds
exactly. `LongDictionary.getStringValue()` returns `Long.toString(...)`, so
reading a TIMESTAMP column as a string already gives raw millis, not a
formatted timestamp — and a BOOLEAN column gives `"1"`. The string view is the
*stored* form for logical types, and user-facing rendering is the result
layer's job, which part 3 already handled: `DataSchema.ColumnDataType.UUID`
converts `ByteArray` to `java.util.UUID`. UUID rendering as hex from the string
view is therefore consistent, not a bug.
Verified empirically rather than by reading: with both the `DataFetcher` and
`BaseTransformFunction` changes reverted, all 235 UUID-related tests still
pass, so nothing depended on them. Net −140 lines.
`CastTransformFunction` keeps its own UUID→STRING rendering, since
`CAST(uuidCol AS STRING)` is an explicit SQL conversion rather than an
incidental string view — that one is covered by `CastTransformFunctionTest`.
--
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]
