For a metaphor.
Replace iPhone -> Oracle
Android -> XML DB
Then watch this video
http://www.youtube.com/watch?v=FL7yD-0pqZg
This is the world I live in ...
and maybe just maybe there is a solution.
----------------------------------------
David A. Lee
Senior Principal Software Engineer
Epocrates, Inc.
[email protected]<mailto:[email protected]>
812-482-5224
From: [email protected]
[mailto:[email protected]] On Behalf Of Lee, David
Sent: Sunday, October 02, 2011 10:09 AM
To: General MarkLogic Developer Discussion
Subject: Re: [MarkLogic Dev General] [xml-dev] JDBC in an XQuery world (?)
Thanks. My 'thought goal' is to see if there is a way to get to the group of
people who are unwilling to consider talking to an XML database (for whatever
reasons). This is both for new/existing code and 3rd party code which we have
no control over.
I'm thinking If I gave them a 'plug & play' JDBC driver then they (people or
existing software) might be more willing to use it. Its the Camel's Nose of
course, once they get used to using an XML DB then they may be more willing to
consider writing code specifically for it.
Hence I'm not looking for "JDBC-Like" or "REST" or some other way but something
that is already in-place as the "standard" way of accessing a database. Aka
JDBC or on windows ODBC.
I know its not ideal. But the target audience is not ideal either. If this
is possible and not *too horrendously ugly* it might solve a huge problem with
adoption of an XML Database in a normally Relational world enterprise.
This is actually a real world problem and I am suggesting the solutions to-date
haven't solved it.
----------------------------------------
David A. Lee
Senior Principal Software Engineer
Epocrates, Inc.
[email protected]<mailto:[email protected]>
812-482-5224
From: [email protected]
[mailto:[email protected]] On Behalf Of Geert Josten
Sent: Sunday, October 02, 2011 4:23 AM
To: General MarkLogic Developer Discussion
Subject: Re: [MarkLogic Dev General] [xml-dev] JDBC in an XQuery world (?)
Sounds soo familiar.. :-/
MarkLogic of course has XDBC / XCC, which I think is a reasonable attempt for
an X-kind of JDBC. Though some of my Java-colleagues were quite happy accessing
MarkLogic Server through REST. There are some standards that help there (JSR,
JAX-WS, JAX-RS), and you don't need to know there is an XML / XQuery database
behind it. (Perhaps that was what they liked most about that approach.. :-P)
Kind regards,
Geert
Van: [email protected]
[mailto:[email protected]] Namens Lee, David
Verzonden: zondag 2 oktober 2011 10:07
Aan: General MarkLogic Developer Discussion
CC: General MarkLogic Developer Discussion
Onderwerp: Re: [MarkLogic Dev General] [xml-dev] JDBC in an XQuery world (?)
Agreed, I wouldn't choose to do it myself. However what I'm brainstorming is
ways to lower the adoption resistance in cases where people or tools are only
interoperable with jdbc or on the windows side odbc.
I'm proposing the community has misjudged the unwillingness for every person
and tool to switch all or nothing to the XQuery koolaid. And thats exactly
what we are asking them to do to adopt something like MarkLogic in the
enterprise.
So if we gave them a bridge, those parts of the ecosystem that won't or can't
change fundamentally could still interface to the server. Then of course they
should eventually change over to the right way. But in many orgs it's very
hard to change ALL tools at once which makes. Adoption of MarkLogic a very high
barrier. And then there are bus critical third party tools vital to a company
that may never change. This could allow their use I. A new ML based system
until the industry matures and more venders come over the fence.
Maybe it's a way to address the chicken and egg problem of change.
Or maybe it's me who drunk too much koolaid.
We have (crude) bridges for XQuery to call RDBMS. But not the other way.
Why not? And would it help?
Sent from my iPad (excuse the terseness)
David A Lee
[email protected]<mailto:[email protected]>
On Oct 2, 2011, at 3:39 AM, "Geert Josten"
<[email protected]<mailto:[email protected]>> wrote:
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:
[email protected]<mailto:[email protected]>
[mailto:[email protected]]<mailto:[mailto:[email protected]]>
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
[email protected]<mailto:[email protected]>
Begin forwarded message:
From: "David Lee" <[email protected]<mailto:[email protected]>>
Date: October 1, 2011 7:57:12 PM EDT
To: <[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>
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
[email protected]<mailto:[email protected]>
http://www.xmlsh.org
_______________________________________________
General mailing list
[email protected]<mailto:[email protected]>
http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
