db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
Date Thu, 24 Aug 2006 20:16:17 GMT
     [ http://issues.apache.org/jira/browse/DERBY-688?page=all ]

A B updated DERBY-688:
----------------------

    Attachment: d688_phase7_v1.patch

Attaching a "phase 7" patch, d1688_v1.patch, that does the following:

  1 - Makes changes to catch all "Throwable" errors that might be
      thrown by Xalan or JAXP, instead of just catching the exceptions
      declared by the APIs.  This is per the email thread here:

      http://www.nabble.com/xalan-assertion-when-execution-a-xml-query...-tf2149830.html#a5953476


      This allows Derby to continue working as normal if/when an
      unexpected Xalan/JAXP error (such NPE or assertion failure)
      occurs.  In that case the statement itself will fail and the
      error will be printed, but Derby will continue to work as
      expected after the failure.

  2 - Slight change so that, in the event of an unexpected Xalan
      compilation error, the name of the operator that encountered
      the error will be printed as part of Derby's message.  Currently
      the operator name isn't passed in and thus "{0}" shows up
      in the error message, which is incorrect.

  3 - Fixes a small bug in XML query execution code that was leading
      to NPEs in Xalan.  Namely, the current code passes a null argument
      into Xalan where a non-null is expected (and required) for namespace
      prefix resolution.

  4 - Makes the first of two changes required to ensure Derby SQL/XML
      support agrees with the specification.  The two changes are
      mentioned in my previous comments; this phase 7 patch addresses
      the first one (insertion of a non-Document node into a Derby XML
      column should not be allowed).

While that may look like a lot of changes, the changes for each of these is quite small and
I believe the changes to be easily reviewable and commitable as a single patch.  If anyone
disagrees, though, please let me know and I can break the changes up into separate patches.

Note that most of d688_phase7_v1.patch is made up of test changes for items #3 and #4.

I applied d688_phase7_v1.patch and ran xmlSuite against sane jars with ibm142 (Windows) and
saw no failures.  So this patch is ready for review/commit.

> Enhancements to XML functionality to move toward XPath/XQuery support...
> ------------------------------------------------------------------------
>
>                 Key: DERBY-688
>                 URL: http://issues.apache.org/jira/browse/DERBY-688
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC, SQL
>            Reporter: A B
>         Assigned To: A B
>            Priority: Minor
>         Attachments: d688_phase1_v1.patch, d688_phase1_v1.stat, d688_phase1_v2.patch,
d688_phase1_v3.patch, d688_phase2_v1_code.patch, d688_phase2_v1_tests.patch, d688_phase2_v2_tests.patch,
d688_phase2_v3_tests.patch, d688_phase3_v1_code.patch, d688_phase3_v1_tests.patch, d688_phase4_v1.patch,
d688_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_v1.patch, d688_phase7_v1.patch, derbyXMLSpec.html
>
>
> As of DERBY-334, Derby has some very basic support for XML that consists of an XML datatype
and three operators (XMLPARSE, XMLSERIALIZE, and XMLEXISTS).  I would like to enhance this
existing functionality and, by doing so, help to move Derby incrementally toward a more usable
and more complete XPath/XQuery solution (with emphasis on "incrementally").
> I have attached to this issue a document describing the particular changes that I am
looking to make.  At a high level, they consist of:
> 1) Making it easier to use the XML operators and datatype from within JDBC (ex. by implicit
parsing/serialization of XML values).
> 2) Adding a new operator, XMLQUERY, to allow a user to retrieve the results of an XPath
expression (instead of just determining whether or not the expression evaluates to an empty
sequence, which is what XMLEXISTS does).
> 3) Making changes to the existing operators to line them up with the SQL/XML 2005 specification,
and also to take steps toward my eventual hope of having support for XQuery (as opposed to
just XPath) in Derby.
> If anyone has time and interest enough to look at the document and provide feedback,
that'd be great...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message