[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Attachment: d688_phase1_v1.patch
d688_phase1_v1.stat
Attaching a "phase 1" patch, d688_phase1_v1.patch, for this issue that does the
following:
1. Reorganizes XML-specific code as follows:
- Moves all code that relies on JAXP and Xalan classes
out of XML.java and into a new class, SqlXmlUtil.java.
See comments at the beginning of SqlXmlUtil for an
explanation of why this was done.
- Creates a new class, SqlXmlExecutor, in the impl.sql.execute
package that serves as the class on which all XML operator
calls are generated. Ex. for XMLEXISTS, instead of
generating:
<xmlOperand>.XMLExists(<query-expr>, xmlOperand)
we now generate:
<SqlXmlExecutor>.XMLSerialize(<query-expr>, xmlOperand)
Along with making the code cleaner by allowing all
XML operator calls to be defined in the same class,
this new class has other benefits, as well--see
comments at the beginning of SqlXmlExecutor for
more of an explanation.
2. Changes implementation of XPath from XSLT processing to
the low-level Xalan API, which is faster, more flexible,
and better for implementation of the XMLQUERY operator
(the XMLQUERY operator will be coming in subsequent
phases). Note that as part of this change I've removed
the dependency on an explicit declaration of Xerces
as the parser; Derby will now pick up the parser from
the JVM (i.e. this patch resolves DERBY-567).
3. Makes a small change to the XMLEXISTS operator to bring
it more in line with SQL/XML spec. More specifically,
the query expression that is specified must now be a string
literal; parameters and other expressions are not allowed.
4. Updates the XML test and master files (lang/xml_general.sql
and lang/xmlBinding.java) to bring them in sync with the latest
Derby codeline. Since the XML tests are not (yet) run
as part of derbyall, the master files need to be updated
to reflect some client/server changes that have gone into
the codeline for 10.2 (for example, server pre-fetching
behavior).
Of these changes the only one that is a functional change is #3; the rest are
internal changes that should have no external effect on the way the XML
operators work. They are important, though, because they lay the groundwork
for subsequent work as described in the HTML document for this issue.
I did try to break the patch up into the different pieces outlined above, but
after two days of trying to undo my work for the sake of elegant, smaller
patches, I decided the patch is acceptable as it is (believe it or not, I did
actually take a lot out of it already). I'll shoot for incremental
development and smaller patches as I work on the subquent changes for this
issue...
I ran derbyall with an earlier version of this patch and there were no new
failures. The latest version (which is the d688_phase1_v1.patch that I'm
posting here) has some updates, though, so I need to run derbyall again.
In the meantime, reviews/comments/feedback would be appreciated.
> 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,
> 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
