db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5546) ResultSet#updateBigDecimal on a REAL column does not do underflow checking
Date Wed, 06 Feb 2013 04:21:12 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572136#comment-13572136
] 

Dag H. Wanvik commented on DERBY-5546:
--------------------------------------

Hmm, no I am no longer so sure that DataTruncation is applicable here: Cf. the below analysis.

SQL 2011 4.4.2 Characteristics of numbers

"A number is assignable only to sites of numeric type. If an assignment of some number would
result in a loss of its most significant digit, an exception condition is raised. If least
significant digits are lost, implementation defined rounding or truncating occurs, with no
exception condition being raised."

The SQL state DATA_EXCEPTION_STRING_DATA_RIGHT_TRUNCATION (22001) would seem *not* to fit.
The SQL state WARNING_STRING_DATA_RIGHT_TRUNCATION_WARNING (01004) would seem *not* to fit.

The SQL state DATA_EXCEPTION_ERROR_IN_ASSIGNMENT (22005) and others
e.g. DATA_EXCEPTION_NUMERIC_VALUE_OUT_OF_RANGE (22003) would seem to
fit.


JDBC specification 4.1 (quote)

"The DataTruncation class,
------------------------
a sub-class of SQLWarning, provides information when data is truncated. When data truncation
occurs on a write to the data source, a DataTruncation object is thrown. The data value that
has been truncated may have been written to the data source even if a warning has been generated.
When data truncation occurs on a read from the data source, a SQLWarning is reported.  A DataTruncation
object contains the following information:

:
■ the SQLState "01004" when data truncation occurs on a read from the data source
■ the SQLState "22001" when data truncation occurs on a write to the data source
:

The SQLDataException class
--------------------------
Table 8-1 specifies which NonTransientSQLException subclass must be thrown for a a given SQLState
class value:

--------------------------------------
| 22___      |   SQLDataException    !
--------------------------------------
"

[Aside: this would seem to conflict the instructions earlier under DataTruncation to throw
the class for 22001, but let's assume the instruction to use DataTruncation overrides this
one... ]

Also: SQLDataException can be thrown for vendor specific reasons.

Note that both DataTruncation and SQLDataException are tied to SQL state 22___. The former
is a SQLWarning, the latter is a full SQLException.

So, agaian, for what subcodes of 22___ should one use DataTruncation or SQLDataException?
 The SQL standard itself specifies many 22___ states, all of which have the name prefix "DATA_EXCEPTION".

For 22001, which JDBC ties to DataTruncation, the SQL name is
DATA_EXCEPTION_STRING_DATA_RIGHT_TRUNCATION.
For 01004 which JDBC ties to DataTruncation, the SQL name is
WARNING_STRING_DATA_RIGHT_TRUNCATION_WARNING.

So this all leads me to wonder whether DataTruncation should only be used for string types
(thrown or reported as the case may be), and numeric types should throw SQLDataException (if
most significant digits can't be preserved), or be silent if rounding/truncation of least
significant digits occur.








                
> ResultSet#updateBigDecimal on a REAL column does not do underflow checking
> --------------------------------------------------------------------------
>
>                 Key: DERBY-5546
>                 URL: https://issues.apache.org/jira/browse/DERBY-5546
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.8.2.2
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>            Priority: Minor
>              Labels: derby_triage10_9
>         Attachments: derby-5546.diff, derby-5546.stat, MissingUnderflowCheck.java
>
>
> In contrast, ResultSet#updateBigDecimal on a FLOAT or DOUBLE column gives the expected
error on underflow. Cf. the attached repro program MissingUnderflowCheck.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message