db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-688) Enhancements to XML functionality to move toward XPath/XQuery support...
Date Wed, 09 Nov 2005 00:28:20 GMT
    [ 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


Mime
View raw message