It might indeed. But suppose we had a JDBC interface, then Hibernate would work 'right out of the box' ! No new API needed. The issue I'm pondering is the unwillingness of people (or existing tools) to use new API's. If people are willing to write to a new API then that issue is already solved, there are many existing API's for XQuery databases.
So I'm not (in this thought hexperiment ) looking at "Whats the best API for XQUery" but rather "Is it possible to shoehorn XQuery into the existing API's so it no longer is a brick wall used to say 'we cant do that because we have to rewrite XYZ or none of our tools support that ' From: Michael Sokolov [mailto:sokolov@ifactory.com] Just a quick thought - it might make more sense to think about providing an object-style interface than JDBC, don't you think? It seems as if there is a substantial set of users that are learning Hibernate and never really write much SQL, and don't interface directly w/JDBC except in odd cases. And an object model could very well be a better match for the XML results. 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').
Not sure where this is going :) ... but I am thinking surely this must have been thought of and implemented so far. 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 |