drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Nadeau (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DRILL-3014) Casting unknown field yields different result from casting null, and bad error message
Date Tue, 12 May 2015 20:01:00 GMT

     [ https://issues.apache.org/jira/browse/DRILL-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jacques Nadeau updated DRILL-3014:
----------------------------------
    Component/s: Execution - Relational Operators

> Casting unknown field yields different result from casting null, and bad error message
> --------------------------------------------------------------------------------------
>
>                 Key: DRILL-3014
>                 URL: https://issues.apache.org/jira/browse/DRILL-3014
>             Project: Apache Drill
>          Issue Type: Bug
>          Components: Execution - Relational Operators
>            Reporter: Daniel Barclay (Drill)
>             Fix For: 1.1.0
>
>
> Casting null to INTEGER works as expected like this:
> {noformat}
> 0: jdbc:drill:zk=local> select  cast(NULL AS  INTEGER) from `dfs.tmp`.`simple.csv`;
> +------------+
> |   EXPR$0   |
> +------------+
> | null       |
> +------------+
> 1 row selected (0.15 seconds)
> 0: jdbc:drill:zk=local>
> {noformat}
> (File "{{simple.csv}}" contains one line containing simply "{{a,b,c,d}}".)
> However, casting an unknown column yields an error:
> {noformat}
> 0: jdbc:drill:zk=local> select  cast(noSuchField AS  INTEGER) from `dfs.tmp`.`simple.csv`;
> Error: SYSTEM ERROR: null
> Fragment 0:0
> [Error Id: a0b348ec-f2c5-4f66-9f05-591399f3c315 on dev-linux2:31010] (state=,code=0)
> 0: jdbc:drill:zk=local>
> {noformat}
> This looks like a JDK {{NumberFormatException}} that wasn't handled properly*, and looks
like the logical null from the non-existent column was turned into the string "{{null}}" before
the cast to {{INTEGER}}.
> Is that a bug or is it intentional that the non-existent field in this case is not actually
treated as being all nulls (as non-existent fields are in at least some other places)?
> (*For most NumberFormatExceptions, the message text does not contain the information
that the kind of exception was a number-format exception--that information is only in the
class name.  In particular that information is not in the message text returned by getMessage().
> Drill code that can throw a {{NumberFormatException}} (e.g., cast functions and other
code that calls, e.g., {{Integer.parse(...)}}) should either immediately wrap it in a {{UserException}},
or at least wrap it in another {{NumberFormatException}} with fuller message text.)
> This seem to confirm that it's a {{NumberFormatException}} (note the first-column value
"{{a}}"):
> {noformat}
> select  cast(columns[0] AS  INTEGER) from `dfs.tmp`.`simple.csv`;
> Error: SYSTEM ERROR: a
> Fragment 0:0
> [Error Id: 9d6107dc-dc2a-40ce-9676-6387ab427098 on dev-linux2:31010] (state=,code=0)
> 0: jdbc:drill:zk=local>
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message