[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Attachment: d688_phase4_v1.patch
d688_phase5_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
code.
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 conflict.
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:
http://thread.gmane.org/gmane.comp.apache.db.derby.devel/25307/focus=25315
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
