You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Daniel Barclay (Drill) (JIRA)" <ji...@apache.org> on 2015/04/09 23:30:12 UTC
[jira] [Comment Edited] (DRILL-2613) Implement (higher-priority)
ResultSet.getXxx(...) data conversions
[ https://issues.apache.org/jira/browse/DRILL-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14384892#comment-14384892 ]
Daniel Barclay (Drill) edited comment on DRILL-2613 at 4/9/15 9:30 PM:
-----------------------------------------------------------------------
[Original title: Implement (higher-priority) ResultSet.getXxx(...) data conversions]
Notes on requirements, possibilities, considerations, etc:
- The JDBC specification (PDF file) does not seem to require any conversions. It does have a matrix (in 4.1) or table (in 4.2) about conversions, but it seems to specify _allowed_ conversions, not _required_ conversions. (Note that it has a column labeled "Java Object Type" with entries such as "getFloat" (a _method_ name), so ...)
- The JDBC spec's section 8.3 does seem to specify reporting some truncation of data upon reading using warnings. However, it's not clear whether that applies to truncation of long values (e.g., long strings), numeric truncation in conversions, or both. Because the spec. refers to SQLState codes for string truncation, that section does not seem to apply to numeric truncation.
- Other JDBC drivers implement some conversions. It is not yet clear what is typical of JDBC drivers or is expected of them by tools calling JDBC.
- Conversion from a narrower type (e.g., INTEGER/int) to a wider type (BIGINT/long) should work fine.
- For conversion from a wider type to a narrower type, there is the question of what happens if the value of the wider type is not a value of the narrower type (doesn't fit in the narrower type). Should that dynamic case throw an exception? Should it ignore the overflow? Should it be a warning (returning a truncated value and adding a SQLWarning to the ResultSet's list of warnings)? Should conversion from a wide type to a narrower type not be supported?
was (Author: dsbos):
Notes on requirements, possibilities, considerations, etc:
- The JDBC specification (PDF file) does not seem to require any conversions. It does have a matrix (in 4.1) or table (in 4.2) about conversions, but it seems to specify _allowed_ conversions, not _required_ conversions. (Note that it has a column labeled "Java Object Type" with entries such as "getFloat" (a _method_ name), so ...)
- The JDBC spec's section 8.3 does seem to specify reporting some truncation of data upon reading using warnings. However, it's not clear whether that applies to truncation of long values (e.g., long strings), numeric truncation in conversions, or both. Because the spec. refers to SQLState codes for string truncation, that section does not seem to apply to numeric truncation.
- Other JDBC drivers implement some conversions. It is not yet clear what is typical of JDBC drivers or is expected of them by tools calling JDBC.
- Conversion from a narrower type (e.g., INTEGER/int) to a wider type (BIGINT/long) should work fine.
- For conversion from a wider type to a narrower type, there is the question of what happens if the value of the wider type is not a value of the narrower type (doesn't fit in the narrower type). Should that dynamic case throw an exception? Should it ignore the overflow? Should it be a warning (returning a truncated value and adding a SQLWarning to the ResultSet's list of warnings)? Should conversion from a wide type to a narrower type not be supported?
> Implement (higher-priority) ResultSet.getXxx(...) data conversions
> ------------------------------------------------------------------
>
> Key: DRILL-2613
> URL: https://issues.apache.org/jira/browse/DRILL-2613
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC
> Reporter: Daniel Barclay (Drill)
> Assignee: Daniel Barclay (Drill)
> Priority: Blocker
> Fix For: 0.9.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)