db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
Date Thu, 10 Aug 2006 16:48:15 GMT
     [ 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

> 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


View raw message