Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Wed, 13 Feb 2013 06:36:13 +0000 (UTC)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12388178.1202468708505.282522.1360737373618@arcas>
In-Reply-To: <JIRA.12388178.1202468708505@arcas>
References: <JIRA.12388178.1202468708505@arcas>
Subject: [jira] [Comment Edited] (DERBY-3398) Support min/max values for
 Java types float/double in real/double columns
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Dag H. Wanvik edited comment on DERBY-3398 at 2/13/13 6:35 AM:
---------------------------------------------------------------

Uploading a patch (#4) which changes the way we check dictionary version in NumberDataType:

On seeing values outside the old DB2 ranges that are otherwise legal (i.e. not infinity or NaN), we check if the current dictionary level is high enough.
Iff we have an lcc (language connection context, we use that to find the dictionary version). If not we rely on a new short field in NumberDataType poked into the DVD at the time the value is set (ResultSret#updateXXX, PreparedStatement#setXXX). This is a similar approach to that used by Kristian when handling the CLOB header versioning. It seems to work, but running full regressions now, and I'll add more tests later if we decide to use this approach.

There are two downsides, one minor and one slightly less so:

- iff the value is outside the old limist (and only then), we some some extra (costly?) processing to check the dictionary version.
- we have added a short member to all NumberDataType classes (increases heap usage by 4 or 8 bytes pr value object depending on the VMs allocation strategy.)

As before, the patch relies on  the patch for DERBY-5546. Another quirk shows up though; for some reason when I compile the patched source, I get an error: it seems the compilation of the iapi.types classes trigger a compile of EmbedResultSet, which fails, presumably since the iapi classes are compiled with a too low source level: javac complains about not finding enough implementations in ERS. An incremental compile of the patch works though. I'll look into why this happens.

                
      was (Author: dagw):
    Uploading a patch (#4) which changes the way we check dictionary version in NumberDataType:

On seeing values outside the old DB2 ranges that are otherwise legal (i.e. not infinity or NaN), we check if the current dictionary level is high enough.
Iff we have an lcc (language connection context, we use that to find the dictionary version). If not we rely on a new short field in NumberDataType poked into the DVD at the time the value is set (ResultSret#updateXXX, PreparedStatement#setXXX). This is a similar approach to that used by Kristian when handling the CLOB header versioning. It seems to work, but running full regressions now, and I'll add more tests later if we decide to use this approach.

There are two downsides, one minor and one slightly less so:

- iff the value is outside the old limist (and only then), we some some extra (costly?) processing to check the dictionary version.
- we have added a short member to all NumberDataType classes (increases heap usage by 4 or 8 bytes pr value object depending on the VMs allocation strategy.)

As before, the patch relies on  the patch for DERBY-5546. Another quick shows up though; for some reason when I compile the patched source, I get an error: it seems the compilation of the iapi.types classes trigger a compile of EmbedResultSet, which fails, presumably since the iapi classes are compiled with a too low source level: javac complains about not finding enough implementations in ERS. An incremental compile of the patch works though. I'll look into why this happens.

                  
> Support min/max values for Java types float/double in real/double columns
> -------------------------------------------------------------------------
>
>                 Key: DERBY-3398
>                 URL: https://issues.apache.org/jira/browse/DERBY-3398
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions: 10.4.1.3
>            Reporter: Knut Anders Hatlen
>            Priority: Minor
>              Labels: derby_triage10_10
>         Attachments: derby-3398-2.diff, derby-3398-3.diff, derby-3398-3.stat, derby-3398.diff, derby-3398.status
>
>
> Derby doesn't support the entire range of valid (finite) values of the Java primitive types double/float in columns with SQL type DOUBLE or REAL. This appears to be a limitation that was introduced for compatibility with DB2. There have been some requests on derby-user that we lift this restriction.
> The restriction is enforced by the methods normalizeREAL() and normalizeDOUBLE() in org.apache.derby.iapi.types.NumberDataType.

--
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