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 Mon, 31 Jul 2006 18:47:14 GMT
     [ 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

        

Mime
View raw message