[
https://issues.apache.org/jira/browse/DRILL-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Westin updated DRILL-3138:
--------------------------------
Fix Version/s: 1.3.0
> 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)
> Assignee: 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)
