You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm migrating from Core-C++ to Core-Java. But while reading data of type CHAR(n), I found the BytesColumnVector.length in Java has a different semantic compared with StringVectorBatch.length in C++. In Java, with the following code, it refers to the number of bytes with padding blanks trimmed, while length in C++ refers to the total number of bytes including padding blanks. For example, reading value 'ABC' of CHAR(10) in Java will get a length 3 instead of 10 in C++. I'm wondering why trimmed lengths are preferred in Java.
PS: Maybe any one of these implementation is acceptable for you, as long as the semantics are same among APIs of different programming languages, but I have to say that the 'redundant' processing in Java did annoy me. I have to reallocate a byte array and pad the bytes again manually for further usage. And the trimmed lengths prevent me from using direct memory copy (although this is still achievable if I'd like to depend on the internal implementation).
I'm migrating from Core-C++ to Core-Java. But while reading data of type
CHAR(n)
, I found theBytesColumnVector.length
in Java has a different semantic compared withStringVectorBatch.length
in C++. In Java, with the following code, it refers to the number of bytes with padding blanks trimmed, whilelength
in C++ refers to the total number of bytes including padding blanks. For example, reading value'ABC'
ofCHAR(10)
in Java will get a length3
instead of10
in C++. I'm wondering why trimmed lengths are preferred in Java.PS: Maybe any one of these implementation is acceptable for you, as long as the semantics are same among APIs of different programming languages, but I have to say that the 'redundant' processing in Java did annoy me. I have to reallocate a byte array and pad the bytes again manually for further usage. And the trimmed lengths prevent me from using direct memory copy (although this is still achievable if I'd like to depend on the internal implementation).
The text was updated successfully, but these errors were encountered: