kgyrtkirk commented on code in PR #15735:
URL: https://github.com/apache/druid/pull/15735#discussion_r1471260321
##########
processing/src/main/java/org/apache/druid/data/input/Rows.java:
##########
@@ -77,6 +79,8 @@ public static List<String> objectToStrings(final Object
inputValue)
} else if (inputValue instanceof byte[]) {
// convert byte[] to base64 encoded string
return Collections.singletonList(StringUtils.encodeBase64String((byte[])
inputValue));
+ } else if (inputValue instanceof ByteBuffer) {
+ return Collections.singletonList(StringUtils.fromUtf8(((ByteBuffer)
inputValue).array()));
Review Comment:
I've came to a conclusion that the right way to handle `ByteBuffer` is to
follow `byte[]` - and produce base64 stuff.
I was looking at where all these `ByteBuffer`-s were created; and it as
introduced in
[PR13773](https://github.com/apache/druid/pull/13773/files#diff-f9a20a5cf47545bdca8b9c2fba92a4705a3841380d35ada27b4d8574066e00feR100-R108).
right now I think that part is causing this issue: it discards the `String`
object and creates `ByteBuffer`-s instead - because its hard to know if later
on if its a `ByteBuffer` because it was a string - but its `ByteBuffer` form; I
think it would be easier to just leave it as `String`.
But this still leaves a question about the comment about:
> If the column is String type, we likely got String objects instead of utf8
bytes, so convert to utf8Bytes
how that could happen? One think I was wondering about: could it be that the
serialized/deserialized frame mutates the `String`-s into `ByteBuffer`-s? I
don't think that should happen - instead the Frame should restore the same type
I've added a commit which have undone those changes - and all test have
passed...not sure if its needed
--
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]
