Hi David, This big problem with ANY api for XQuery would be to re-introduce a separation between application-layer and database-layer, that could equally well be left out. The benefit of a real-life application built in XQuery-only, or perhaps XRX, is that because these layers are much closer integrated, the code is much easier to understand, and much easier to maintain.
Apart from that, there are a few existing api’s, like XQJ, but not sure that is what you are looking for.. Kind regards, Geert Van: general-boun...@developer.marklogic.com [mailto:general-boun...@developer.marklogic.com] Namens Lee, David Verzonden: zondag 2 oktober 2011 4:52 Aan: General Mark Logic Developer Discussion Onderwerp: [MarkLogic Dev General] Fwd: [xml-dev] JDBC in an XQuery world (?) Forwarding this to the ML list because that is the first platform I'm considering Comments greatly welcome Sent from my iPad (excuse the terseness) David A Lee d...@calldei.com<mailto:d...@calldei.com> Begin forwarded message: From: "David Lee" <d...@calldei.com<mailto:d...@calldei.com>> Date: October 1, 2011 7:57:12 PM EDT To: <xml-...@lists.xml.org<mailto:xml-...@lists.xml.org>>, <t...@x-query.com<mailto:t...@x-query.com>> Subject: [xml-dev] JDBC in an XQuery world (?) 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 d...@calldei.com<mailto:d...@calldei.com> http://www.xmlsh.org
_______________________________________________ General mailing list General@developer.marklogic.com http://developer.marklogic.com/mailman/listinfo/general
