[
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
