[Fdo-trac] [fdo-trac] #734: Problem reading negative Int64 values

[FDO]

#734: Problem reading negative Int64 values
---------------------------------+----------------------
 Reporter:  simonpel             |        Owner:  haris
     Type:  defect               |       Status:  closed
 Priority:  major                |    Milestone:  3.5.0
Component:  KingOracle Provider  |      Version:  3.5.0
 Severity:  3                    |   Resolution:  fixed
 Keywords:                       |  External ID:
---------------------------------+----------------------
Changes (by jng):

 * resolution:   => fixed
 * status:  new => closed

Comment:

 In [changeset:"8400" 8400]:
 {{{#!CommitTicketReference repository="" revision="8400"
 Ticket #734: Negative values and unrecognized OCI conversion failures

 Ticket #734 ("Problem reading negative Int64 values") reports that reading
 a
 negative Int64 returns "GetInt64 : Exception unrecognized" and crashes the
 client. Two things were behind that, and this change set covers both.

 Reading the value: the provider narrows the Oracle NUMBER it fetched back
 to a
 C integer with OCINumberToInt, and that conversion has to be told the
 value is
 signed. The 3.5-era code performed it as OCI_NUMBER_UNSIGNED inside
 GetLong(),
 so Oracle rejected every negative value (ORA-01426). GetLong() was
 replaced by
 GetInt64() (OCI_NUMBER_SIGNED, sizeof(FdoInt64)) in r7061, which also
 switched
 GetInteger() to OCI_NUMBER_SIGNED, so the reported case already passes on
 this
 branch; no provider change was needed for it, and what was missing was
 coverage.

 Reporting the failure: when an accessor cannot narrow the value it read,
 OCI
 reports it through a raw c_Oci_Exception, and that is where the ticket's
 "Exception unrecognized" comes from - a client cannot interpret that type.
 The
 numeric accessors of both readers now raise the FdoCommandException a
 client
 can read, carrying the OCI message ("OCI-22053: overflow error"), which
 also
 removes c_KgOraReader::GetInt32's catch that printed the error and
 returned 0:
 an unreadable value was indistinguishable from a genuine zero.

 Provider:
 * c_OCI_API: OciErrorToFdoException() turns the c_Oci_Exception an
 accessor
   reported into an FdoCommandException carrying the OCI text, taking over
 the
   exception it is given.
 * c_KgOraReader: GetInt16, GetInt32, GetInt64, GetSingle and GetDouble
 route
   their statement accessor's OCI error through it.
 * c_KgOraSQLDataReader: the same five accessors.

 Tests:
 * DataTypeTests::NegativeNumbers reads negative values back through
   FdoISQLDataReader for every width OCINumberToInt narrows - Int16, Int32
 and
   Int64 (NUMBER(4,0), NUMBER(9,0), NUMBER(19,0)), plus Single, Double and
 a
   scaled NUMBER - once with a small negative and once with the smallest
 value
   the column can hold, asserting the FDO types reported for the columns
 too.
 * DataTypeTests::NegativeFeatureValues covers the feature commands: a
 negative
   identity and Int32 are inserted with FdoIInsert and the identity is read
 back
   from the command's own reader, then read by an equality filter built
 from an
   FdoInt64Value, by a text range filter and through an ordered select, and
 an
   update and a delete are executed against a filter matching the negative
 key.
   It also asserts that reading the Int64 minimum through GetInt32 raises
   instead of returning 0.
 * DataTypeTests::NumberOutOfRange asserts that a NUMBER(19,0) holding 19
 nines
   - one row negative, one positive - fails as an FdoException carrying the
 OCI
   text rather than as an unrecognized exception, and that the Int64
 minimum,
   which does fit Int64, is still readable through the same statement.

 Verified with the full KgOraUnitTest suite against Oracle XE 11g: OK (42)
 in
 the Debug (ASan) and Release configurations, the Debug run with no
 LeakSanitizer report. Both halves were also run against the behaviour they
 replace: with OCI_NUMBER_UNSIGNED restored in c_Oci_Statement the two
 value
 tests fail, and with OciErrorToFdoException rethrowing the raw
 c_Oci_Exception
 instead of converting it, the two reporting tests fail - each with an
 uncaught exception of unknown type,
 the client-visible form of the error ticket #734 reports - while the
 pre-existing cases still pass.

 Fixes #734
 }}}
-- 
Ticket URL: <https://trac.osgeo.org/fdo/ticket/734#comment:1>
FDO <http://fdo.osgeo.org/>
Feature Data Objects