[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Attachment: d688_phase3_v1_code.patch
d688_phase3_v1_tests.patch
Attaching a "phase 3" patch that implements the XMLQUERY operator. The patch
is in two parts:
- d688_phase3_v1_code.patch
- d688_phase3_v1_tests.patch
When committed, though, *both* patches should be committed together in order to
avoid test diffs.
The SQL parsing/compile time logic was added as part of the phase 2 patch; this
patch handles the execution-time logic by making the necessary Xalan calls to
evaluate an expression and to retrieve the results.
The phase 3 patch also adds logic to distinguish between two "types" of XML:
XML(DOCUMENT(ANY)) and XML(SEQUENCE), as defined in the SQL/XML[2006]
specification. The reason we need to distinguish between the two is that the
result of evaluating an XML query expression against an XML document can be an
arbitrary list of items including atomic values, attributes, etc.--i.e. a
sequence of items that is *not* required to form a valid DOCUMENT node. For
now, though, we only allow valid DOCUMENTs to be inserted into XML columns, so
we have to be able to look at the results of the XMLQUERY operator to determine
whether or not it's a valid DOCUMENT, and if not we disallow insertion of that
result into an XML column. We can, however, keep the result transiently and
pass it into other operations that accept an XML value (namely, XMLSERIALIZE,
which a user can then use to retrieve the results in serialized form).
NOTE: The phase 3 changes rely on the Phase 1 AND Phase 2 changes, which have
not yet been committed. The phase 3 diffs are created w.r.t the phase 1 and
phase 2 diffs and thus the phase 3 patches will not apply unless the other have
been applied first.
I ran derbyall on Red Hat Linux with ibm142 after applying all patches and
there were no new failures. I also ran xmlSuite on Windows 2000 with ibm142
and all tests passed there, as well.
I'm still looking for someone to review/commit any/all of these patches. Just
to clarify, the following patches are up for review/commit and must be
applied/committed in the order shown:
1. d688_phase1_v3.patch
2. d688_phase2_v1_code.patch
3. d688_phase2_v3_tests.patch
4. d688_phase3_v1_code.patch
5. d688_phase3_v1_tests.patch
Thanks.
> 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, 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
