db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrna van Lunteren <m.v.lunte...@gmail.com>
Subject Re: SQLXML Research report
Date Mon, 05 Apr 2010 16:36:10 GMT
2010/4/3 Ян Программист <webautomator@gmail.com>

>  While figuring out necessary information about SQLXML, I found that it is
> a JDBC 4 issue, according to SQL 2003(?) standard specification. I found
> following databases containing SQLXML implementation:
>
>
>
> SQL Server 2008
>
> HyperSQL
>
> PostgreSQL
>
>
>
> Other databases have XML support in SQL syntax, for example H2 database,
> but I haven't found anything about SQLXML in their JDBC API
>
>
>
> So I digged a bit in HyperSQL API Javadoc, and here is what I've found in
> org.hsqldb.jdbc.JDBCSQLXML.html:
>
>
>
>
>
> “*HSQLDB-Specific Information:*
>
>
>
> Starting with HSQLDB 1.9.0, a rudimentary client-side SQLXML interface
> implementation (this class) is supported for local use when the product is
> built and run under JDK 1.6+ and the SQLXML instance is constructed as the
> result of calling JDBCConnection.createSQLXML().
>
>
>
> SQLXML instances retrieved in such a fashion are initially write-only, with
> the lifecycle of read and write availability constrained in accordance with
> the documentation of the interface methods.
>
>
>
> When build and run under JDK 1.6+, it is also possible to retrieve
> read-only SQLXML instances from JDBCResultSet.getSQLXML(...), given that
> the underlying data can be converted to an XML Document Object Model (DOM).
>
>
>
> However, at the time of this writing (2007-06-12) it is not yet possible
> to store SQLXML objects directly into an HSQLDB database or to use them
> directly for HSQLDB statement parameterization purposes. This is because the
> SQLXML data type is not yet natively supported by the HSQLDB engine.
> Instead, a JDBCSQLXML instance must first be read as a string, binary input
> stream, character input stream and so on, which can then be used for such
> purposes.
>
>
>
> Here is the current read/write availability lifecycle for JDBCSQLXML:
>
>
>
> Origin
>
> Initially
>
> After 1st Write
>
> After 1st Read
>
> After 1st Free
>
> *org.hsqldb.jdbc.JDBC**Connection**.createSQLXML()*
>
> Write-only
>
> Read-only
>
> Not readable or writable
>
> Not readable or writable
>
> *org.hsqldb.jdbc.JDBC**ResultSet**.getSQLXML(...)*
>
> Read-only
>
> N/A
>
> Not readable or writable
>
> Not readable or writable
>
> .”
>
>
>
> My conclusions:
>
>    1. Hence a difference in class purpose, between JDBCConnection &
>    JDBCResultSet
>
> ◦                  JDBCConnection is obviously dictates data exange mode.
> Looks similar to global XML mode in MySQL, stating from version 5
>
> ◦                  JDBCResultSet implies that some general SQL request is
> performed already. An that is *exactly what I was seeking* for:
>
>
>
> So I continued my lookup and found this in HyperSQL source code:
>
>  [...]
>


John,

I am not a lawyer, but I frown on the copying without license notice of
exact source code. I frown on copying the source code altogether.

Please be more careful. I know HyperSQL is also open source, but I rely on
our derby community being very circumspect about what license we use and
accept. The HyperSQL license is *not* the apache license, and I do not even
want to see their source code.
When you're doing further work on this, please be sure not to copy this
code.

Thank you.
Myrna van Lunteren

Mime
View raw message