[ https://issues.apache.org/jira/browse/DRILL-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Westin updated DRILL-3138: -------------------------------- Component/s: Client - HTTP Client - CLI > Doc.: BINARY example "B@e6d9eb7" doesn't make sense > --------------------------------------------------- > > Key: DRILL-3138 > URL: https://issues.apache.org/jira/browse/DRILL-3138 > Project: Apache Drill > Issue Type: Bug > Components: Client - CLI, Client - HTTP > Reporter: Daniel Barclay (Drill) > Fix For: 1.3.0 > > > On the Supported Data Types page at > http://drill.apache.org/docs/supported-data-types/, the example value of > "{{B@e6d9eb7}}" for type {{BINARY}} doesn't make sense. > Strings like "{{[B@e6d9eb7}}" result from calling method {{toString()}} on > Java byte arrays (objects of type {{byte[]}} (represented as "{{[B}}" > internally). The hex digits represent the hash code of the object. > In particular, those hex digits are not a representation of the BINARY value. > They have no relationship to the bytes contained in and the BINARY value > represented by the object of type byte[]. (Two different objects containing > the same sequence of bytes have different "[B@..." strings.) > > The root problem appears to be that our two user interfaces to Drill (SQLLine > and the web UI) display such "{{[B@...}}" strings rather than displaying > binary string values reasonably. > (They should render a BINARY value into a string of characters that actually > represents the string of bytes in the BINARY value (perhaps as a SQL > {{<binary string literal>}}).) -- This message was sent by Atlassian JIRA (v6.3.4#6332)