db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2739) Use DOM interfaces to implement XML operators
Date Fri, 18 Feb 2011 14:35:38 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-2739:

    Attachment: xml-interfaces-2.diff

Attaching a new patch, xml-interfaces-2.diff, which supersedes the
xml-interfaces.diff patch. There aren't many differences between the
two patches, so the description in the comment from 03/Jan/11 is still
accurate. Also note the svn magic mentioned in that comment to
reintroduce tools/java/xml-apis.jar for the build.

The new patch adds some more comments, and it addresses the only known
outstanding issue with the previous patch, that is, formatting of
numbers returned by XPath queries had changed from the original

In short, the problem was that the previous patch used
Double.toString() to format the numbers, which caused these

  - scientific notation was used for sufficiently small or big
    numbers, for instance "1.23E-5" instead of "0.0000123"

  - trailing zeros after the decimal point weren't removed, so we'd
    get "14.0" instead of "14"

Especially this latter difference caused problems, for example when
inserting results from XPath queries into columns of type INT, since
the former string ("14.0") couldn't be cast to INT. The XPath
libraries return all numbers as double values, so there's no way to
know whether the query actually returned the integer 14 or the
floating point number 14.0.

In this patch, the formatting of numbers is changed back to how it
used to be. The original implementation would format numbers the same
way as the XPath string function, as described here:

I didn't find any method in the Java class library that formatted the
numbers exactly that way, but I found that BigDecimal.toPlainString()
was very close, and if we manually removed trailing zeros (including
the decimal point if the entire fraction part is zero), the results
seemed to be identical to the old results, and the tests passed.

Now the problem was that toPlainString() was a new method in Java 5,
so it's not avaialble on Java 1.4 or CDC Foundation Profile 1.1, which
we still need to support. Luckily, on those older platforms,
BigDecimal.toString() is defined the same way as toPlainString() on
newer platforms. The definition of toString() was changed in Java 5,
so we cannot use that method on all platforms, but using
toPlainString() when available and falling back to toString()
otherwise, seems to give consistent results across the platforms
(tested with 1.4.2, 1.5.0 and 1.6.0).

The resulting code in SqlXmlUtil.numberToString() is a bit ugly, using
reflection to call the correct method, but I thought that doing it
this way was less error-prone than writing our own code to format the
numbers manually.

> Use DOM interfaces to implement XML operators
> ---------------------------------------------
>                 Key: DERBY-2739
>                 URL: https://issues.apache.org/jira/browse/DERBY-2739
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: infinity-NaN.diff, ns-npe.diff, numeric-tests.diff, stricter-assertions.diff,
xml-interfaces-2.diff, xml-interfaces.diff
> Sun's Java 1.5.0 and higher includes Xalan, but Derby doesn't find it because it has
been moved to a non-standard package. Derby should be able to detect and use these classes
if it cannot find Xalan in the standard package on the classpath. This would make it easier
for many users to start using Derby's XML features.
> See also the discussion in this thread: <URL:http://mail-archives.apache.org/mod_mbox/db-derby-dev/200705.mbox/%3c465F015C.9070404@gmail.com%3e>

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message