From 'the beginning' there has been a lot
of talk (and some actual work/products) which interface XQuery
to a relational back end.
A good deal of the design of XQuery (from
my thousand-meter high view) was designed so it could map to a
relational model or at least a relational database.
There are papers, talks, and products which
do this to varying degrees of success.
But what about the other way? What if I
have (or want) an XQuery database (or would you call that a
XML database with an XQuery interface ...?) and expose it to
relational-minded clients ? There's a huge existing ecosystem
which understands the relational model, or the relational
API's. Simply saying "oh just use this NEW API instead"
doesn't make everyone happy. But if we could say 'Just use
this new JDBC driver' ... hmmm
Suppose we had a JDBC interface to
XQuery/XML databases ? Sure it wouldn't be the best choice
... but then neither is using JDBC for Oracle or MySQL ...
there are even JDBC drivers for CSV files
.. . But its used ... a LOT ! Why ? Not because it's the
best choice, but because its omnipresent and just works.
Programmers learn one API and use it across the board. They
then console themselves believing that they could switch
vendors if they wanted (ya right) ... but its a nice
comfortable illusion. For some reason few really care that
you CANT switch from MySQL to Oracle by just swapping out the
JDBC driver ... because the SQL itself is incompatible. But
since the API is the same we live in this nice fantasy world.
Unicorns and rainbow lollipops for everyone.
Is that so bad ? Seems like it's not
really ...
I've been thinking .. Suppose we had a
JDBC driver that could talk 'native' to an XQuery backend DB ?
1) What problems would it solve ?
2) What would it look like ?
#1 ... problems. There's a lot of
applications out there that can be given an JDBC driver and
'just work with it'. These might instantly become "XQuery
Aware".
Well maybe not .. but maybe they could do
*something* given an JDBC connection to a XQuery database
where before they could do nothing at all.
#2 what would it look like ? I'm not
talking about writing a SQL->XQuery mapping (although
that's an interesting project in itself, maybe in V(n+1) ),
but from an API layer ... JDBC just takes
any old SQL string and executes it and returns a result set.
The fact that MySQL and Oracle and DB2 and SQl/Server are
entirely incompatible in SQL doesn't cause much problems as
its 'just a string'. Suppose this new JDBC driver took
XQuery as the "sql' string. What could it do ?
The issues I think of are
#A Binding of '?' variables. these
translate neatly into XQuery external variables, but a simple
case could simply not support them. I'm not sure if
Connection.prepareStatement() *requires* support for "?"
bindings ? I'm sure we could come up with some kind of
convention to handle them. I do something similar in xmlsh
where I prepend any XQuery within <[ xquery statement ]>
with a set of 'declare variable $_n extern' ... which lets you
use external variables implicitly without predeceasing them.
Same concept could work so that JDBC's
PreparedStatement.setInteger( field , value ) could work
against an XQuery statement.
#B Result sets. Here's the fun. What does
XQuery return ? XDM. How to map XDM to a JDBC result set ?
Would each item in the sequence be a row or
column ? If a row then what is its type ? JDBC allows you
to query the type of every column so that implies that each
row's corresponding column must be the same type. Not true if
XDM sequences are rows. Is this a requirement ? What if it
just faked out the type of the first "row" ... what would
break ? Maybe only apps that read the catalog and assume all
rows have the same structure (1 column of type 'x' most likely
'string').
Or the result set could be a single row where each item is a
column. Atomic XDM types map fairly well to JDBC types.
XML types could be a kind of BLOB or VARCHAR ...
Not sure where this is going :) ... but I
am thinking surely this must have been thought of and
implemented so far.
But I haven't seen it. Anyone know of any work in this
direction ?
Anyone think of any good use cases ?
I'm thinking this might be a way of
leveraging XML Databases in an otherwise 'relational shop' ...
and if taken up might encourage XML DB Vendors to put a bit
more effort into supporting the things that relational DB's
are actually good at ... Joins ...
Maybe this might lead to a standard (or
'common') SQL -> XQuery mapping.
Ideas ? Tomatoes ?
-David
----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org
