You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "A B (JIRA)" <de...@db.apache.org> on 2005/11/08 02:37:21 UTC
[jira] Created: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
Enhancements to XML functionality to move toward XPath/XQuery support...
------------------------------------------------------------------------
Key: DERBY-688
URL: http://issues.apache.org/jira/browse/DERBY-688
Project: Derby
Type: Improvement
Components: JDBC, SQL
Reporter: A B
Assigned to: A B
Priority: Minor
Attachments: 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
Re: [jira] Updated: (DERBY-688) Enhancements to XML functionality
to move toward XPath/XQuery support...
Posted by Bryan Pendleton <bp...@amberpoint.com>.
> A B updated DERBY-688:
> ----------------------
>
> Attachment: d688_phase4_v2.patch
Thanks for the quick response Army!
I am intending to review and commit the phase4 and phase5 patches tonight.
thanks,
bryan
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Attachment: d688_phase4_v2.patch
Attaching a second version of the phase 4 patch that corrects the test failure reported by Bryan. The real reason I had the EXPORT commands in the test to begin with was because I assumed that the IMPORT command would check for the target file before checking the validity of the columns, and so I used a (successful) EXPORT command to create the file. Luckily, that assumption was wrong: the import command first checks the types of the columns and *then* looks for the file, and since the new test cases should fail due to the XML type, the actual file specified is never accessed, and thus it doesn't even have to exist.
So I've updated the phase 4 test case to give bogus file names for the IMPORT commands since they don't matter. And I also removed the successful EXPORT command that created the file which was throwing the SecurityException.
No other changes exist between d688_phase4_v1 and d688_phase4_v2.
Also, my derbyall run with these XML changes ran with no new errors last night. I ran on SuSE Linux with ibm142 against insane jars.
I think the phase 4 and phase 5 patches are now ready for commit (in that order), unless further review comments are made.
This wraps up the *functional* changes for XML that I'd like to get into 10.2 There are still, however, some other tasks to complete:
- Fix-up new error messages. All of the error messages for the
DERBY-688 changes thus far have been added as "X0X...", but
it recently occured to me that are those reserved for
"execution time" errors. Many of the new XML messages are
actually compile-time errors and thus they probably should
have different SQLSTATEs. So I'll have to look at that.
- Complete the documentation of the new operators (see DERBY-1655)
- Fix xmlBinding test to address diff reported by Bryan and
which I also see when running on Linux.
- Add new tests to verify Derby behavior when XML classes are
not present.
- Enable tests to run as part of derbyall (for those jvms
that have the required classes).
- Add more descriptive comments of the diff between BY REF
and BY VALUE, probably in sqlgrammar.jj
- For completeness, I need to update the spec attached to this issue
to reflect the behavior that's actually been implemented (which is a
subset of the functionality described in the spec (ex. no JDBC support).
The first two items are the only ones that are visible to the user, so those need to be completed first.
> 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_phase4_v2.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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Attachment: derbyXMLSpec.html
> Enhancements to XML functionality to move toward XPath/XQuery support...
> ------------------------------------------------------------------------
>
> Key: DERBY-688
> URL: http://issues.apache.org/jira/browse/DERBY-688
> Project: Derby
> Type: Improvement
> Components: JDBC, SQL
> Reporter: A B
> Assignee: A B
> Priority: Minor
> Attachments: 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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12357097 ]
Rick Hillegas commented on DERBY-688:
-------------------------------------
Good spec. I have some initial comments on the Usability section:
The spec needs to be enriched by familiarity with JDBC 4.0, which is where the JDBC support for XML appears. To download draft 2 of the spec, see the following webpage: http://www.jcp.org/en/jsr/detail?id=221. For the accompanying javadoc, see http://download.java.net/jdk6/doc/api/index.html.
In a nutshell, JDBC 4.0 is the client api which ships with jdk1.6. We are building support for JDBC 4.0 into the 10.2 release of Derby. Key features of the JDBC 4.0 XML support include:
o the java.sql.Types.SQLXML type code
o the corresponding vendor-supplied implementation of the java.sql.SQLXML interface
o stream readers and writers for this datatype: javax.xml.stream.XMLStreamReader and javax.xml.stream.XMLStreamWriter
o PreparedStatement.setSQLXML() and ResultSet.getSQLXML()
Given this JDBC support, I think that we can improve on the Usability of the XML datatype. I agree that we should be able to select and insert directly from/into columns of this type. However, the compiler should not implicitly wrap these column references with XMLSERIALIZE and XMLPARSE. Instead, the following implementation makes sense to me:
The 10.2 server should allow clients to do the following:
o Create columns of type XML (as is done today)
o Select these columns without any wrapping
o Insert into these columns without any wrapping
The 10.2 Derby client running on jdk1.6 will support JDBC 4.0. In particular, it will provide PreparedStatement and ResultSet support for selecting and inserting java.sql.SQLXML values.
The other client/server combinations can play out as follows. In the following discussion, I use the term OldClient to mean:
- The DB2JCC client
- The 10.1 client
- A 10.2 client running on jdk1.3 (JDBC 2), jdk1.4 (JDBC 3), or jdk1.5 (JDBC 3)
o If any client attempts to directly insert/select an XML column in a 10.1 server, the server will simply raise an exception. That's what it does today.
o If an OldClient attempts to directly insert/select an XML column from a 10.2 server, the server will raise an error in the network layer because the XML datavalue cannot be transported to those less capable clients.
o However, any client can issue ResultSet.getString() and PreparedStatement.setString() on XML columns in a 10.2 server. This will result in the server coercing the XML datavalue to/from a string using XMLPARSE and XMLSERIALIZE.
> Enhancements to XML functionality to move toward XPath/XQuery support...
> ------------------------------------------------------------------------
>
> Key: DERBY-688
> URL: http://issues.apache.org/jira/browse/DERBY-688
> Project: Derby
> Type: Improvement
> Components: JDBC, SQL
> Reporter: A B
> Assignee: A B
> Priority: Minor
> Attachments: 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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12430532 ]
A B commented on DERBY-688:
---------------------------
> Merged the phase7 patch to the 10.2 branch as revision 434583.
Thank you, Bryan, for continuing to review and commit the patches for this issue the whole way through. I appreciate your time and thoroughness!
> Cleared Patch Available. Is it time to mark this issue resolved?
I think that the work commited for this issue puts Derby XML support into an acceptable state for exposing "first step" XML support that is in line with the relevant standards (namely, SQL/XML 2006). The remaining work has been separated out into two new Jira issues that can be addressed independently, one of which (DERBY-1759) is important for standards compliance and thus is next on my list for 10.2 (hopefully).
While those two remaining tasks do need to be completed, I think that Derby XML support as of the "phase 7" commit is in a form that is "complete enough" for the 10.2 release (with the potential need for a release note if DERBY-1759 isn't resolved by then).
Thus I believe this issue can be resolved and closed. If I don't hear any objections by the end of today (PST on 08/25), that's what I'll do. Any other bugs/tasks that come up can then be filed as separate Jira issues.
Thanks again to Bryan for his continued reviews/commits, Yip for his review of the initial patches, and to David Van Couvering for an initial review of the doc patches (see DERBY-1655).
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_v1.patch, d688_phase7_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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Attachment: d688_phase2_v1_code.patch
d688_phase2_v1_tests.patch
Attaching a "phase 2" patch that does the following:
- Adds syntax and binding logic for XMLQUERY operator
- Updates syntax for XMLEXISTS to match XMLQUERY and does some refactoring so that the two can share code. The most user-visible change in this area is the change from BY VALUE to BY REF syntax, which required test updates and corresponding master file updates.
Also as part of these changes I've rewritten some of the parse logic to make it more easily extendible to a broader XMLQUERY syntax (as defined in SQL/XML[2006]) when/if Derby supports the broader syntax (esp. optional context items and variable bindings) in the future.
- These phase 2 patches do *not* actually implement the XMLQUERY operator yet; they just allow parsing and binding of the operator. Execution-time logic will come in a subsequent patch.
For the sake of review I've separated the Phase 2 patches into two different parts:
d688_phase2_v1_code.patch: The code changes.
d688_phase2_v1_tests.patch: The test/master changes.
When committed, though, *both* patches should be committed together in order to avoid test diffs.
NOTE: The phase 2 changes rely on the Phase 1 changes, which have not yet been committed. The phase 2 diffs are created w.r.t the phase 1 diffs and thus the phase 2 patches will not apply unless the phase 1 patch has been applied first.
I'm still looking for someone to review/commit the phase 1patch (d688_phase1_v3.patch).
I ran derbyall on Windows 2000 with ibm142 after applying the phase 1 patch AND both phase 2 patches; there were no new failures. I also ran xmlSuite and all XML-specific tests passed.
If anyone has time to review the phase 1 and/or phase 2 patches, I'd be grateful.
> 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, 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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12427249 ]
A B commented on DERBY-688:
---------------------------
Thanks for continuing to review the patches, Bryan. The whole security thing with the "xmlexport.del" file did occur to me, but when I ran the tests it passed so I thought it was fine. But that was because I was running against the classes directory; I keep forgetting to avoid doing that.
The fact that test results are the same between phase 4 and phase 5 patches is expected since the phase 5 patch hasn't added any new tests. I'm thinking I'll add the appropriate phase 5 tests as another "phase" (along with the other test-related changes that I have to do, like fix xmlBinding diff).
In the meantime, I'll look at the export test and see how to get around the security exception. Thank you for your feedback!
> 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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12430271 ]
A B commented on DERBY-688:
---------------------------
I've created two new Jira issue, DERBY-1758 and DERBY-1759, for the remaining XML work described in the comments for this issue. I think that those remaining tasks could require a non-trivial effort and thus they merit they own Jira issues.
Thus, if/when the phase 7 patch is reviewed/committed, I think we can close this issue (finally) and then work on the other issues separately. Note that the new issues (esp. the testing one, DERBY-1758) may not make it into the 10.2 release, but should still be addressed sooner rather than later. If DERBY-1759 does not make it, then at the very least a release note will be needed to call out the fact that Derby 10.2 doesn't follow SQL/XML serialization rules in some cases.
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_v1.patch, d688_phase7_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
[jira] Resolved: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B resolved DERBY-688.
-----------------------
Fix Version/s: 10.2.2.0
10.3.0.0
Resolution: Fixed
All patches committed to trunk and 10.2 for a while now, and follow-up work is being tracked in separate Jira issues, as mentioned in previous comment. So resolving this issue.
> 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: SQL, JDBC
> Reporter: A B
> Assigned To: A B
> Priority: Minor
> Fix For: 10.2.2.0, 10.3.0.0
>
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_v1.patch, d688_phase7_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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12427391 ]
Bryan Pendleton commented on DERBY-688:
---------------------------------------
Committed d688_patch4_v2.patch to subversion as revision 430626
> 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_phase4_v2.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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12426616 ]
Bryan Pendleton commented on DERBY-688:
---------------------------------------
d688_phase1_v3.patch committed to subversion as revision 429698.
> 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: SQL, JDBC
> 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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12429588 ]
Bryan Pendleton commented on DERBY-688:
---------------------------------------
Does the phase6 patch need to be applied to the 10.2 branch?
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
Bryan Pendleton updated DERBY-688:
----------------------------------
Derby Info: (was: [Patch Available])
patch d688_patch_v5.txt committed to subversion as revision 430670.
Clearing patch_available as all pending patches have been committed.
> 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_phase4_v2.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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Derby Info: [Patch Available]
> 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: SQL, JDBC
> Reporter: A B
> Assigned To: A B
> Priority: Minor
> Attachments: d688_phase1_v1.patch, d688_phase1_v1.stat, d688_phase1_v2.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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Derby Info: [Patch Available]
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_v1.patch, d688_phase7_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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12428837 ]
A B commented on DERBY-688:
---------------------------
As I was writing up the documentation for the XML operators, I was also double-checking the features to make sure they were all in-line with the SQL/XML[2006] specification. After some searching around I've realized that there are two ways in which the current XML operators are not in line with the spec:
1. Currently one can use XMLQUERY to retrieve a single element
node from an XML value and then insert that element directly
into another Derby XML column. However, SQL/XML spec says
that a column of type XML(DOCUMENT)--which is what Derby's
columns are--can only store actual DOCUMENT nodes; element
nodes cannot be implicitly "morphed" into document nodes.
Instead, one must use the XMLDOCUMENT() operator, which is
not yet implemented in Derby. So basically, I have to make
changes to disallow this kind of insertion.
2. When serializing the results of an XMLQUERY operator, the
current code doesn't strictly follow the SQL/XML specification,
which dictates that the sequence must be "normalized" before
it is serialized. The rules for normalization can be found
here:
http://www.w3.org/TR/xslt-xquery-serialization/#serdm
So changes have to be made in SqlXmlUtil.serializeToString()
to implement these rules.
Thus, there are still two outstanding code-related tasks for DERBY-688:
A. Fix SQLSTATEs: I have a patch ready, just haven't posted it yet.
Will try to do it soon.
B. Resolve two situations listed above w.r.t to following SQL/XML
specifications.
I think both of these things need to be completed for the 10.2 release in order to 1) make sure Derby is a standards-based database, per the charter, and 2) minimize likelihood for "Existing Application Impact" issues in subsequent releases (caused by having to change behavior or sqlstates).
> 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_phase4_v2.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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Attachment: d688_phase2_v2_tests.patch
Attaching a new version of the "phase2_tests" patch since the first version doesn't appear to apply cleanly. In particular, the DerbyNetClient/xml_general.out master file looks to have conflicts. The new patch is "d688_phase2_v2_tests.patch".
> 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: SQL, JDBC
> 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, 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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Derby Info: [Patch Available]
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ 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
Re: [jira] Updated: (DERBY-688) Enhancements to XML functionality
to move toward XPath/XQuery support...
Posted by Army <qo...@gmail.com>.
David Van Couvering wrote:
> and thanks for the careful review and effort by Brian and Yip!
Agreed!
> I am telling people "we have XML features" and I know it's
> something to do with XQuery and XPath, but I couldn't say what.
>
> Did these patches include documentation? Or is that forthcoming?
Documentation is still forthcoming, as are some additional patches to finalize
the work. There're still a couple of tasks to complete--such as enabling tests
to run as part of derbyall--but the bulk of it is now in the codeline.
Documentation is one of the remaining tasks.
Army
Re: XML in Derby - WAS : [jira] Updated: (DERBY-688) Enhancements
to XML functionality to move toward XPath/XQuery support...
Posted by Daniel John Debrunner <dj...@apache.org>.
Kristian Waagan wrote:
> Daniel John Debrunner wrote:
>
>> David Van Couvering wrote:
>>
>>> Wow, great work Army, and thanks for the careful review and effort by
>>> Brian and Yip! It's great to have this in. If I could only grok
>>> exactly what the feature is and how I might use it :) I am telling
>>> people "we have XML features" and I know it's something to do with
>>> XQuery and XPath, but I couldn't say what.
>>
>>
>> I was messing with the XML support last night for buddy testing and it's
>> very cool. Three new Derby features combined together to make the
>> application development easier:
>>
>> 1) XML support
>> 2) CALL procedure in trigger
>> 3) Lengthless overrides for PreparedStatement.setCharacterStream
>>
>> OK - I didn't test 3) cos I would have to set up Xalan for Mustang and I
>> didn't want to spend time on how to figure that out, but it would have
>> been useful.
>
>
> Hi Dan,
>
> This sounds really cool :)
> Any change you can share your trigger procedure?
> Then maybe someone else can take on the work to test the new lengthless
> overrides added by JDBC 4.0. I don't think they have received much
> testing yet. They are now in the 10.2 branch, but I believe they are not
> (fully) included in the latest beta (10.2.1.1). I'll add an entry to the
> buddy testing page when the time is right.
Here's the Java method:
public static void get_url_content(String id, String path)
throws SQLException, IOException
{
Connection conn =
DriverManager.getConnection("jdbc:default:connection");
PreparedStatement ps = conn.prepareStatement(
"UPDATE WDD.WEB_DOCS SET WD_CONTENT = " +
"XMLPARSE (DOCUMENT CAST (? AS CLOB) PRESERVE WHITESPACE)" +
" , WD_ACCESSTIME = CURRENT TIMESTAMP " +
"WHERE WD_ID = ?");
ps.setString(2, id);
URL url = new URL(path);
URLConnection urlConn = url.openConnection();
urlConn.connect();
int length = urlConn.getContentLength();
String enc = urlConn.getContentEncoding();
if (enc == null)
enc = "UTF-8";
InputStream in = urlConn.getInputStream();
InputStreamReader isr = new InputStreamReader(in, enc);
// HACK - Assume number of characters will be
// the same as the number of bytes.
ps.setCharacterStream(1, isr, length);
ps.execute();
in.close();
ps.close();
conn.close();
}
and the SQL
DROP TABLE WDD.WEB_DOCS;
CREATE TABLE WDD.WEB_DOCS (
WD_ID VARCHAR(128) PRIMARY KEY,
WD_URL VARCHAR(1000),
WD_CONTENT XML,
WD_ACCESSTIME TIMESTAMP
);
DROP PROCEDURE WDD.GET_URL_CONTENT;
CREATE PROCEDURE WDD.GET_URL_CONTENT(ID VARCHAR(128), URL VARCHAR(1000))
LANGUAGE JAVA PARAMETER STYLE JAVA
EXTERNAL NAME 'wdd.get_url_content';
CREATE TRIGGER WDD.WD_I AFTER INSERT
ON WDD.WEB_DOCS
REFERENCING NEW AS NEW
FOR EACH ROW MODE DB2SQL
CALL WDD.GET_URL_CONTENT(NEW.WD_ID, NEW.WD_URL);
Dan.
Re: XML in Derby - WAS : [jira] Updated: (DERBY-688) Enhancements to
XML functionality to move toward XPath/XQuery support...
Posted by Kristian Waagan <Kr...@Sun.COM>.
Daniel John Debrunner wrote:
> David Van Couvering wrote:
>
>> Wow, great work Army, and thanks for the careful review and effort by
>> Brian and Yip! It's great to have this in. If I could only grok
>> exactly what the feature is and how I might use it :) I am telling
>> people "we have XML features" and I know it's something to do with
>> XQuery and XPath, but I couldn't say what.
>
> I was messing with the XML support last night for buddy testing and it's
> very cool. Three new Derby features combined together to make the
> application development easier:
>
> 1) XML support
> 2) CALL procedure in trigger
> 3) Lengthless overrides for PreparedStatement.setCharacterStream
>
> OK - I didn't test 3) cos I would have to set up Xalan for Mustang and I
> didn't want to spend time on how to figure that out, but it would have
> been useful.
Hi Dan,
This sounds really cool :)
Any change you can share your trigger procedure?
Then maybe someone else can take on the work to test the new lengthless
overrides added by JDBC 4.0. I don't think they have received much
testing yet. They are now in the 10.2 branch, but I believe they are not
(fully) included in the latest beta (10.2.1.1). I'll add an entry to the
buddy testing page when the time is right.
Regards,
--
Kristian
>
> I setup a table with a column that contained a URL as a VARCHAR and an
> XML column, a procedure in an INSERT trigger then fetched the data from
> the URL and updated the XML column using XMLPARSE, streaming directly
> from the remote site using setCharacterStream.
>
> I used this to download DERBY Jira issues, each row holds an XML
> document that corresponds to a single Jira issue. E.g. from
>
> http://issues.apache.org/jira/browse/DERBY-434?decorator=none&view=rss
>
> Then I can execute queries against the issues locally, using XPath (and
> SQL).
>
> -- Sequence of all comments made by Sunitha against bugs reported by me
> -- wd_id is the DERBY-XXX identifier
> -- wd_accesstime is the time the data was downloaded from the web.
> -- wd_content is the XML column
>
> select wd_id, wd_accesstime,
> XMLSERIALIZE(
> XMLQUERY('//item/comments/comment[@author="skambha"]' PASSING BY REF
> wd_content EMPTY ON EMPTY)
> AS VARCHAR(30000))
> from wdd.web_docs where
> XMLEXISTS('//reporter[text() = "Daniel John Debrunner"]' PASSING BY REF
> wd_content);
>
> -- Jira status of all bugs entered by me
>
> select wd_id,
> XMLSERIALIZE(
> XMLQUERY('//item/status/text()' PASSING BY REF wd_content EMPTY ON EMPTY)
> AS VARCHAR(20)),
> wd_accesstime
> from wdd.web_docs where
> XMLEXISTS('//reporter[text() = "Daniel John Debrunner"]' PASSING BY REF
> wd_content)
> order by 2,1;
>
> I'll think I wil expand this to use it in my talk at ApacheCon US.
> Dan.
>
>
>
>
>
>
>
>
XML in Derby - WAS : [jira] Updated: (DERBY-688) Enhancements to
XML functionality to move toward XPath/XQuery support...
Posted by Daniel John Debrunner <dj...@apache.org>.
David Van Couvering wrote:
> Wow, great work Army, and thanks for the careful review and effort by
> Brian and Yip! It's great to have this in. If I could only grok
> exactly what the feature is and how I might use it :) I am telling
> people "we have XML features" and I know it's something to do with
> XQuery and XPath, but I couldn't say what.
I was messing with the XML support last night for buddy testing and it's
very cool. Three new Derby features combined together to make the
application development easier:
1) XML support
2) CALL procedure in trigger
3) Lengthless overrides for PreparedStatement.setCharacterStream
OK - I didn't test 3) cos I would have to set up Xalan for Mustang and I
didn't want to spend time on how to figure that out, but it would have
been useful.
I setup a table with a column that contained a URL as a VARCHAR and an
XML column, a procedure in an INSERT trigger then fetched the data from
the URL and updated the XML column using XMLPARSE, streaming directly
from the remote site using setCharacterStream.
I used this to download DERBY Jira issues, each row holds an XML
document that corresponds to a single Jira issue. E.g. from
http://issues.apache.org/jira/browse/DERBY-434?decorator=none&view=rss
Then I can execute queries against the issues locally, using XPath (and
SQL).
-- Sequence of all comments made by Sunitha against bugs reported by me
-- wd_id is the DERBY-XXX identifier
-- wd_accesstime is the time the data was downloaded from the web.
-- wd_content is the XML column
select wd_id, wd_accesstime,
XMLSERIALIZE(
XMLQUERY('//item/comments/comment[@author="skambha"]' PASSING BY REF
wd_content EMPTY ON EMPTY)
AS VARCHAR(30000))
from wdd.web_docs where
XMLEXISTS('//reporter[text() = "Daniel John Debrunner"]' PASSING BY REF
wd_content);
-- Jira status of all bugs entered by me
select wd_id,
XMLSERIALIZE(
XMLQUERY('//item/status/text()' PASSING BY REF wd_content EMPTY ON EMPTY)
AS VARCHAR(20)),
wd_accesstime
from wdd.web_docs where
XMLEXISTS('//reporter[text() = "Daniel John Debrunner"]' PASSING BY REF
wd_content)
order by 2,1;
I'll think I wil expand this to use it in my talk at ApacheCon US.
Dan.
Re: [jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by David Van Couvering <Da...@Sun.COM>.
Wow, great work Army, and thanks for the careful review and effort by
Brian and Yip! It's great to have this in. If I could only grok
exactly what the feature is and how I might use it :) I am telling
people "we have XML features" and I know it's something to do with
XQuery and XPath, but I couldn't say what.
Did these patches include documentation? Or is that forthcoming?
David
Bryan Pendleton (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
>
> Bryan Pendleton updated DERBY-688:
> ----------------------------------
>
> Derby Info: (was: [Patch Available])
>
> Committed d688_phase3_v1_code.patch and d688_phase3_v1_tests.patch
> to subversion as revision 429847. Committed the two patches together per
> Army's recommendation to commit these patches as a unit to avoid test diffs.
>
> Clearing the patch available flag because all the pending patches have now been committed.
>
> Thanks for all the hard work on this, Army!
>
>
>> 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: SQL, JDBC
>> 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...
>
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
Bryan Pendleton updated DERBY-688:
----------------------------------
Derby Info: (was: [Patch Available])
Committed d688_phase3_v1_code.patch and d688_phase3_v1_tests.patch
to subversion as revision 429847. Committed the two patches together per
Army's recommendation to commit these patches as a unit to avoid test diffs.
Clearing the patch available flag because all the pending patches have now been committed.
Thanks for all the hard work on this, Army!
> 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: SQL, JDBC
> 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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Attachment: d688_phase2_v3_tests.patch
Oops, I was wrong about the "phase 2" test patch--that was user error. I have too many uncommitted patches for this issue on my machine so I mixed them up. Attaching another version, d688_phase2_v3_tests.patch, that corrects my mix up. Sorry for the confusion.
> 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, 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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12427430 ]
A B commented on DERBY-688:
---------------------------
> Committed d688_patch4_v2.patch to subversion as revision 430626
> patch d688_patch_v5.txt committed to subversion as revision 430670.
I sync'd, rebuilt and ran some tests (xmlSuite on Windows 2000) and everything looks good. Thanks a ton for the reviews and for the commits, Bryan. I appreciate it!
> 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_phase4_v2.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
Re: [jira] Commented: (DERBY-688) Enhancements to XML functionality
to move toward XPath/XQuery support...
Posted by Army <qo...@gmail.com>.
Daniel John Debrunner wrote:
> svn diff works with relative names from the top level
<snip examples>
I think all of those examples assume the diffs that you're trying to get are
w.r.t the svn trunk? Since none of the patches have been committed to the
trunk, I need to get diffs between two svn clients on the same machine in order
to build sequential patches. To do that I'm using "diff --unified" and
specifying the paths to the two clients, hence the absolute path names.
But as I said, I'll make sure the absolute path names are removed in future patches.
Army
Re: [jira] Commented: (DERBY-688) Enhancements to XML functionality
to move toward XPath/XQuery support...
Posted by Daniel John Debrunner <dj...@apache.org>.
A B (JIRA) wrote:
> Sorry, this was because I had to write some scripts/helper programs to generate the sequential patches with respect to each other (since none of them have been committed yet, a simple 'svn diff' wouldn't work) and the scripts use the full path names.
svn diff works with relative names from the top level
# just changes to engine
svn diff java/engine
# just changes to engine and testing
svn diff java/engine java/testing
# just diffs to two files
svn diff NOTICE COPYRIGHT
etc. etc.
Dan.
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12425979 ]
A B commented on DERBY-688:
---------------------------
> Note to reviewers (and to Army): the "phase2" and "phase3" patches
> appear to have been generated with full absolute file names rather than
> with relative file names,
Sorry, this was because I had to write some scripts/helper programs to generate the sequential patches with respect to each other (since none of them have been committed yet, a simple 'svn diff' wouldn't work) and the scripts use the full path names.
> I don't think there's any need to repost all the patches just to fix this,
> but if we end up reposting them later, this would be a nice thing to
> clean up.
Thanks Bryan. For any reposts that are necessary I will indeed make the required changes before posting the patch.
> 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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12430356 ]
Bryan Pendleton commented on DERBY-688:
---------------------------------------
The phase 7 patch looks good to me. It reads clearly and matche the description. I built the code and ran derbyall without complaint, and the xml test suite ran as expected using Xalan 2.7. Committed the phase 7 patch to the trunk as revision 434556.
I intend to merge this revision back to the 10.2 branch as well.
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_v1.patch, d688_phase7_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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Derby Info: [Patch Available]
> 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: SQL, JDBC
> 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
Re: [jira] Updated: (DERBY-688) Enhancements to XML functionality
to move toward XPath/XQuery support...
Posted by Bryan Pendleton <bp...@amberpoint.com>.
A B (JIRA) wrote:
> So this patch, d688_phase6_v1.patch, is ready for commit.
Thanks Army!
I intend to review and commit this change. If anyone else is
reviewing it, please let me know.
thanks,
bryan
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Attachment: d688_phase6_v1.patch
Attaching a phase 6 patch, d688_phase6_v1.patch, that changes the SQLSTATEs for XML errors to match the SQL/XML specification where possible, and that moves the Derby-specific XML sql states to a compile-time range (42Z70 - 42Z7Z) instead of an execution-time range (X0Xxx).
I applied the patch, did an ant clobber followed by an ant all, then ran xmlSuite with ibm142 and all tests passed (Windows).
So this patch, d688_phase6_v1.patch, is ready for commit.
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Derby Info: [Release Note Needed]
Adding a release note to call out Derby's dependency on a JAXP parser and Apache Xalan when executing XML operators. First attempt at the release note is as follows:
DERBY-688: XML datatype and corresponding SQL/XML operators.
As of the 10.2 release, Derby supports a new XML data type and a set of operators that work with the XML data type. The XML data type and operators are based on a small subset of the SQL/XML specification.
PROBLEM
For the XML operators to work properly, Derby requires that a JAXP parser, such as Apache Xerces, and Apache Xalan are included in the Java classpath. If either the parser or Xalan are missing from the classpath, Derby disallows any XML-related operations.
SYMPTOM
If a user attempts to use any of the of XML operators but does not have a JAXP parser AND Apache Xalan in his/her classpath, the result will be an error similar to the following:
Failed to locate '<JAXP/Xalan>' API or implementation classes. XML operations are not permitted unless these classes are in your classpath.
CAUSE
Derby does all XML parsing by making calls to JAXP methods as defined in the JDK 1.4 API. Similarly, Derby does all evaluation of XPath queries, manipulation of XPath results, and serialization of XML values by making calls to Xalan-specific methods defined in Xalan classes. Thus if either JAXP or Xalan is missing from the classpath, the Derby XML operators would not function correctly, leading to ClassNotFound and similar exceptions at various points during code execution. In order to avoid this, Derby checks to see if JAXP and Xalan are in the classpath, and if either is missing, Derby will not even attempt to perform XML operations. Instead, it will just issue the error mentioned above.
SOLUTION
If you intend to use any of the Derby XML operators, make sure that you have 1) a JAXP parser and 2) Apache Xalan in your classpath. If you are running in client/server mode, the JAXP and Xalan classes must be in the classpath for the Derby server, since that is where XML-related processing actually occurs.
Apache Derby version 10.2 has been tested with Xalan 2.7.0. If you have a version of Xalan that is earlier than 2.7, the Derby XML operators may still work. However, it is possible that you will experience unexpected errors when using the Derby XML operators. For example, there is a bug in Xalan versions earlier than 2.5 that can lead to failures with Derby XML operators when Derby is running with a security manager. The exact error can vary depending on the situation, but generally includes a line similar to the following:
org.apache.xml.utils.WrappedRuntimeException: The resource [ file:////org/apache/xalan/serialize/XMLEntities.res ] could not load: java.security.AccessControlException: access denied
This problem has been fixed as of Xalan 2.5, so you can avoid the problem by using a more recent version of Xalan.
Note: Most Java virtual machines (JVMs) that are version 1.4 or later have a JAXP parser embedded in the JVM. If you are using one of these JVMs, you do not need to add any other JAXP classes to your classpath. Additionally, if the JVM that you are using includes an embedded version of Xalan, you should confirm that the version of Xalan satisfies the minimum requirements for Derby. For example, if your JVM is Sun JDK 1.4.2, you must override the version of Xalan in the JVM with a newer version. Use Java's Endorsed Standards Override Mechanisms described at http://java.sun.com/j2se/1.4.2/docs/guide/standards/ to override the version of Xalan.
If the JVM that you are using does not have a JAXP parser or a version of Xalan, you can add external versions of those classes in your classpath and Derby will pick up those classes.
WORKAROUND
There is no way to use the Derby XML operators without first including a JAXP parser and Apache Xalan in your classpath. Attempts to do so will result in an error.
> 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: SQL, JDBC
> Reporter: A B
> Assigned To: A B
> Priority: Minor
> Fix For: 10.2.2.0, 10.3.0.0
>
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_v1.patch, d688_phase7_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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12422163 ]
A B commented on DERBY-688:
---------------------------
While derbyall runs cleanly against my classes directory with these changes, it turns out that there are errors when I run the tests against the jar files. I think this problem is related to what Andrew pointed out in the following thread:
http://article.gmane.org/gmane.comp.apache.db.derby.devel/14459
I will look into this more and make the appropriate changes. Anyone reviewing should still feel free to make comments on the _v1 patch since the code that's there won't change--but that patch should not be committed until I resolve the jar issue. 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, 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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Attachment: d688_phase1_v3.patch
Attaching an updated patch synced with the latest codeline. The only difference between _v2 and _v3 is that the client master file for lang/xml_general.sql has been updated to reflect the latest checkin for DERBY-1029.
> 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, 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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12426762 ]
A B commented on DERBY-688:
---------------------------
Thanks a ton for reviewing and committing this set of the patches, Bryan. I ran the XML tests with the latest codeline and verified that things are as they should be.
Many thanks to Yip for taking the time to review, as well!
For ease of reference, review comments/replies can be found in the following threads:
http://article.gmane.org/gmane.comp.apache.db.derby.devel/25793
http://article.gmane.org/gmane.comp.apache.db.derby.devel/25824
Remaining XML patches are forthcoming, as is documentation for the new functionality.
Thanks again Bryan and Yip (and David VC for recruiting help!).
> 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
Re: [jira] Updated: (DERBY-688) Enhancements to XML functionality
to move toward XPath/XQuery support...
Posted by Army <qo...@gmail.com>.
Bryan Pendleton (JIRA) wrote:
>
> I reviewed d688_phase6_v1.patch and it looks good to me. The
> build was fine, and derbyall ran cleanly. xml_general.sql and
> xmlBinding.java ran as expected with Xalan 2.7. Committed this
> patch to subversion as revision 433450, and cleared the
> PatchAvailable flag.
Thanks Bryan!
Army
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
Bryan Pendleton updated DERBY-688:
----------------------------------
Derby Info: (was: [Patch Available])
I reviewed d688_phase6_v1.patch and it looks good to me. The build was fine, and derbyall ran cleanly. xml_general.sql and xmlBinding.java ran as expected with Xalan 2.7. Committed this patch to subversion as revision 433450, and cleared the PatchAvailable flag.
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_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
Re: [jira] Commented: (DERBY-688) Enhancements to XML functionality
to move toward XPath/XQuery support...
Posted by Bryan Pendleton <bp...@amberpoint.com>.
>> Does the phase6 patch need to be applied to the 10.2 branch?
>
> Yes, that'd be great. Thanks for bringing this up--I'd forgotten about the need for this...
I intend to merge the phase6 patch for DERBY-688 to the 10.2
branch in the next day or so. Rick (or anyone else), please let
me know if you see any problems with this.
thanks,
bryan
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12429739 ]
A B commented on DERBY-688:
---------------------------
> Does the phase6 patch need to be applied to the 10.2 branch?
Yes, that'd be great. Thanks for bringing this up--I'd forgotten about the need for this...
> 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: SQL, JDBC
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
Bryan Pendleton updated DERBY-688:
----------------------------------
Derby Info: (was: [Patch Available])
Merged the phase7 patch to the 10.2 branch as revision 434583.
Cleared Patch Available. Is it time to mark this issue resolved?
> 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: SQL, JDBC
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_v1.patch, d688_phase7_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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Attachment: d688_phase1_v2.patch
Attaching a second patch, d688_phase1_v2.patch, that makes the appropriate changes to ensure that the new classes (esp. SqlXmlExecutor) are included in the jar builds. For the thread indicating what changes to make, see:
http://article.gmane.org/gmane.comp.apache.db.derby.devel/24135
The patch is the same as phase1_v1 except that it has the following additional diffs:
Index: tools/jar/extraDBMSclasses.properties
===================================================================
--- tools/jar/extraDBMSclasses.properties (revision 423655)
+++ tools/jar/extraDBMSclasses.properties (working copy)
@@ -84,4 +84,4 @@
derby.module.store.urlf=org.apache.derby.impl.io.URLFile
derby.module.store.cpf=org.apache.derby.impl.io.CPFile
-derby.module.xml.typec=org.apache.derby.impl.sql.compile.XMLTypeCompiler
+derby.module.xml.sqlxmle=org.apache.derby.impl.sql.execute.SqlXmlExecutor
Index: tools/jar/extraDBMStypes.properties
===================================================================
--- tools/jar/extraDBMStypes.properties (revision 423655)
+++ tools/jar/extraDBMStypes.properties (working copy)
@@ -13,3 +13,4 @@
derby.module.type.m=org.apache.derby.impl.sql.compile.RefTypeCompiler
derby.module.type.n=org.apache.derby.impl.sql.compile.TimeTypeCompiler
derby.module.type.o=org.apache.derby.impl.sql.compile.TimestampTypeCompiler
+derby.module.type.p=org.apache.derby.impl.sql.compile.XMLTypeCompiler
I ran the XML test suite (xmlSuite) with classes and with jars using IBM 1.4.2 and they passed in both cases.
Reviews/feedback are 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: SQL, JDBC
> Reporter: A B
> Assigned To: A B
> Priority: Minor
> Attachments: d688_phase1_v1.patch, d688_phase1_v1.stat, d688_phase1_v2.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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12425965 ]
Bryan Pendleton commented on DERBY-688:
---------------------------------------
Note to reviewers (and to Army): the "phase2" and "phase3" patches appear to have been generated with full
absolute file names rather than with relative file names, which means that the simple technique of
"cd trunk; patch -p0 < PATCH" fails to locate the files. For review purposes, this is straightforward to work around:
once you have downloaded each patch, edit the patch and change the file names to strip out the leading portion
of the absoluate file names, so that, for example:
--- c:/p4clients/main_codeline/opensource/java/testing/org/apache/derbyTesting/functionTests/tests/lang/xml_general.sql Mon Jul 31 11:37:21 2006
+++ c:/private/derby_src/java/testing/org/apache/derbyTesting/functionTests/tests/lang/xml_general.sql Mon Jul 31 09:03:47 2006
becomes
--- java/testing/org/apache/derbyTesting/functionTests/tests/lang/xml_general.sql Mon Jul 31 11:37:21 2006
+++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/xml_general.sql Mon Jul 31 09:03:47 2006
In vim, for example, just do:
:1,$s#c:/p4clients/main_codeline/opensource/##
:1,$s#c:/private/derby_src/##
on each of the phase2 and phase3 patches.
I don't think there's any need to repost all the patches just to fix this, but if we end up reposting them later,
this would be a nice thing to clean up.
> 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: SQL, JDBC
> 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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12427102 ]
Bryan Pendleton commented on DERBY-688:
---------------------------------------
I read through patch 5 also. It looks good to me. It seems like a simple "negative" test of your
new ClassInspector method would be to try to load a non-existent class and verify that it
returns false, and a simple "positive" test would be to try to load a well-known Derby class
and verify that it returns true. Probably could also try a few obvious classes like the ones in
rt.jar. I think these would tend to be junit-type tests, since they are low-level unit tests, not
higher level tests like we usually have. But I think they would still be useful tests.
Patch 5 applied cleanly and built cleanly for me atop patch 4, and I get the same results
for xml_general.sql and xmlBinding.java after patch 5 as I get after patch 4.
> 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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12429876 ]
Bryan Pendleton commented on DERBY-688:
---------------------------------------
Merged d688_phase6_v1.patch to 10.2. Merge was clean and build and test runs were uneventful.
Committed to subversion as revision 433854.
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_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
[jira] Updated: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B updated DERBY-688:
----------------------
Attachment: d688_phase7_v1.patch
Attaching a "phase 7" patch, d1688_v1.patch, that does the following:
1 - Makes changes to catch all "Throwable" errors that might be
thrown by Xalan or JAXP, instead of just catching the exceptions
declared by the APIs. This is per the email thread here:
http://www.nabble.com/xalan-assertion-when-execution-a-xml-query...-tf2149830.html#a5953476
This allows Derby to continue working as normal if/when an
unexpected Xalan/JAXP error (such NPE or assertion failure)
occurs. In that case the statement itself will fail and the
error will be printed, but Derby will continue to work as
expected after the failure.
2 - Slight change so that, in the event of an unexpected Xalan
compilation error, the name of the operator that encountered
the error will be printed as part of Derby's message. Currently
the operator name isn't passed in and thus "{0}" shows up
in the error message, which is incorrect.
3 - Fixes a small bug in XML query execution code that was leading
to NPEs in Xalan. Namely, the current code passes a null argument
into Xalan where a non-null is expected (and required) for namespace
prefix resolution.
4 - Makes the first of two changes required to ensure Derby SQL/XML
support agrees with the specification. The two changes are
mentioned in my previous comments; this phase 7 patch addresses
the first one (insertion of a non-Document node into a Derby XML
column should not be allowed).
While that may look like a lot of changes, the changes for each of these is quite small and I believe the changes to be easily reviewable and commitable as a single patch. If anyone disagrees, though, please let me know and I can break the changes up into separate patches.
Note that most of d688_phase7_v1.patch is made up of test changes for items #3 and #4.
I applied d688_phase7_v1.patch and ran xmlSuite against sane jars with ibm142 (Windows) and saw no failures. So this patch is ready for review/commit.
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_v1.patch, d688_phase7_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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12427085 ]
Bryan Pendleton commented on DERBY-688:
---------------------------------------
I looked at the Phase 4 patch. It applies and builds cleanly for me.
However, when I run lang/xml_general.sql, I get the following diff,
which appears to come from the tests of SYSCS_EXPORT_QUERY.
-bash-2.05b$ java org.apache.derbyTesting.functionTests.harness.RunTest lang/xml_general.sql
*** Start: xml_general jdk1.4.2_11 2006-08-09 19:51:14 ***
137 del
< 0 rows inserted/updated/deleted
137a137,138
> ERROR XJ001: Java exception: 'java.security.AccessControlException: access denied (java.io.FilePermission xmlexport.del write)'.
> ERROR XJ001: Java exception: 'access denied (java.io.FilePermission xmlexport.del write): java.security.AccessControlException'.
141 del
< 0 rows inserted/updated/deleted
141a142,143
> ERROR XJ001: Java exception: 'java.security.AccessControlException: access denied (java.io.FilePermission xmlexport.del write)'.
> ERROR XJ001: Java exception: 'access denied (java.io.FilePermission xmlexport.del write): java.security.AccessControlException'.
Test Failed.
*** End: xml_general jdk1.4.2_11 2006-08-09 19:51:22 ***
> 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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=comments#action_12426673 ]
Bryan Pendleton commented on DERBY-688:
---------------------------------------
Committed d688_phase2_v1_code.patch and d688_phase2_v3_tests.patch
to subversion as revision 429764.
I committed both patches as a single revision according to Army's suggestion above:
> When committed, though, *both* patches should be committed together in order to avoid test diffs.
> 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: SQL, JDBC
> 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
[jira] Closed: (DERBY-688) Enhancements to XML functionality to
move toward XPath/XQuery support...
Posted by "A B (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-688?page=all ]
A B closed DERBY-688.
---------------------
All changes committed (thanks again, Bryan!) and no complaints about the release note text, so marking this issue as closed.
> 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: SQL, JDBC
> Reporter: A B
> Assigned To: A B
> Priority: Minor
> Fix For: 10.2.2.0, 10.3.0.0
>
> 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_phase4_v2.patch, d688_phase5_v1.patch, d688_phase6_v1.patch, d688_phase7_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