You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@drill.apache.org by "Daniel Barclay (Drill) (JIRA)" <ji...@apache.org> on 2015/05/19 00:04:00 UTC

[jira] [Created] (DRILL-3138) Doc.: BINARY example "B@e6d9eb7" doesn't make sense

Daniel Barclay (Drill) created DRILL-3138:
---------------------------------------------

             Summary: 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
            Reporter: Daniel Barclay (Drill)


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.)
&nbsp;

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)