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
Reported by mail by Fabiano Bonin:
My databases have some columns declared as "char(16) character set octets", which i use to store UUIDs.
Jaybird treats these columns as type STRING, except in case the parameter octetsAsBytes is passed to the connection, then it treats
these columns as type BYTES.
When they are treated as STRINGs, when the CRS is loaded from a ResultSet, it usually truncates the field, as i suppose it calls getString() to load the column value, and Java tries to interpred these bytes following some charset and encoding, thus truncating or getting an enexpected behavior depending on the bytes it finds.
Don´t you think it would be better to treat these columns as BYTES as the standard behavior? I think everyone using character set octets uses it to store binary data, or do you see another use for it? Even if eventually an octecs field can store a encoded string, if Jaybird stores its value as BYTES, when the developer calls getString(), it would then convert the bytes to String, and it wouldn´t change the actual behavior, would it?
What do you think about this?
The text was updated successfully, but these errors were encountered:
Submitted by: @mrotteveel
Assigned to: Roman Rokytskyy (rrokytskyy)
Duplicates JDBC240
Reported by mail by Fabiano Bonin:
My databases have some columns declared as "char(16) character set octets", which i use to store UUIDs.
Jaybird treats these columns as type STRING, except in case the parameter octetsAsBytes is passed to the connection, then it treats
these columns as type BYTES.
When they are treated as STRINGs, when the CRS is loaded from a ResultSet, it usually truncates the field, as i suppose it calls getString() to load the column value, and Java tries to interpred these bytes following some charset and encoding, thus truncating or getting an enexpected behavior depending on the bytes it finds.
Don´t you think it would be better to treat these columns as BYTES as the standard behavior? I think everyone using character set octets uses it to store binary data, or do you see another use for it? Even if eventually an octecs field can store a encoded string, if Jaybird stores its value as BYTES, when the developer calls getString(), it would then convert the bytes to String, and it wouldn´t change the actual behavior, would it?
What do you think about this?
The text was updated successfully, but these errors were encountered: