[ 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
