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 Wed, 09 Aug 2006 22:38:18 GMT
     [ http://issues.apache.org/jira/browse/DERBY-688?page=all ]

A B updated DERBY-688:

    Attachment: d688_phase4_v1.patch

Attaching two patches, one for "Phase 4" and one for "Phase 5".

Phase 4:

The phase 4 patch, d688_phase4_v1.patch, adds some additional restrictions to the ways in
which XML values can be used.  In particular:

  1. XML types cannot be used in CREATE PROCEDURE or CREATE FUNCTION statements.

  2. XML types cannot be used in import/export functions.

  3. XML types cannot be declared as columns in a global temp table.

I admit that I'm a bit fuzzy as to *why* these restrictions need to be in place, but these
are the restrictions that apply to the other "long" datatypes in Derby (LOBs, LONG VARCHAR)
so I'm enforcing them for XML, as well, to be safe.  It'll be easier to remove these restrictions
in the future than it will be to block them after users have potentially been relying on them.

One final restriction added by this patch is as follows: if a parameter is used for the operand
to an XMLPARSE operation, the parameter must have an explicit cast to a character string type.
 I've put this restriction in place because, based on my reading of the spec, this is required
for SQL/XML[2006] conformance.  Further explanation can be found in comments for the relevant

d688_phase4_v1.patch also adds some simple test cases for each of these restrictions to the
lang/xml_general.sql test, with the corresponding master updates.

And finally, the phase 4 patch includes two new error messages: one for the XMLPARSE restriction,
and one for missing XML classes, which is actually for phase 5 but I included it in the phase
4 patch so that the two patches can be applied sequentially (phase 4 then phase 5) without

Phase 5:

The phase 5 patch, d688_phase5_v1.patch, adds code to determine whether or not the user's
classpath has the required XML classes and, if not, to throw a user-friendly(-ier) error message
whenver the user attempts to use any of the XML operators.

I inquired as to the best way to do this in the following thread:


Dan suggested a) looking at the Derby code that loads modules, and b) adding a new utility
method to the ClassInspector class.

I looked at the module-loading code and it ultimately just makes a call to Class.forName()
and ignores a module if that call throws a LinkageError or a ClassNotFoundException; see the
getImplementations() method in BaseMonitor.java.  So based on that I added a utility method
to ClassInspector that does the same thing, except that it just returns "true" if the call
to Class.forName() succeeds and "false" otherwise.  I made the new method static because it
doesn't rely on any state specific to ClassInspector and because it would have taken a good
deal of searching for me to figure out how to instantiate an instance of ClassInspector correctly
from within the XML datatype class.

I ran quite a few tests manually with this change to verify that things are working, but I
haven't figured out a good way to add corresponding tests to derbyall.  So there are no such
tests yet.  If anyone has any suggestions that'd be great; otherwise I'm thinking it'd probably
be best to figure that out as a follow-up task to this issue.

After applying both patches, I ran xmlSuite on Windows 2000 with ibm142 and there were no
failures (I still have to look into a diff in xmlBinding.java that occurs on Linux, but that
was already reported by Bryan Pendleton and is not related to these specific patches).

I'll run derbyall tonight as a sanity check, but in the meantime I'd appreciate any reviews/feedback.

As mentioned above, the patches are intended to be applied in sequential order, phase 4 followed
by phase 5, but that does not mean that they both have to be committed at the same time. So
long as phase 4 is committed first, there shouldn't be any issues.

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


View raw message