[jira] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ 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] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ 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] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ 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
Re: [jira] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
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...
[ 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] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ 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] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ 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] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ 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...
[ 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...
[ 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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ 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...
[ 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...
[ 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...
[ 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] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ 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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ 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
Re: [jira] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
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.
Re: [jira] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
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
[jira] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ 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] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
[ 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
