[
Lists Home |
Date Index |
Thread Index
]
Michael,
Michael Kay wrote:
>>Burak Emir wrote:
>>
>>
>>
>>>I just cannot believe that one can seriously want to repeat
>>>
>>>
>>the IMHO biggest design error of JDBC, namely to pass *strings* to
>>the library.
>>
>>
>>>This effectively kills all possibilities of static (compile-time)
>>>verification of queries, like syntax checking (let alone types).
>>>
>>>flabbergasted...
>>>
>>>
>
>Burak, what kind of interface did you have in mind? Is it the "embedded DML"
>kind of interface where query language statements are defined as an
>extension to the basic programming language (i.e. a sublanguage)?
>
>
>
Indeed, but it does not need to be a proper language extension. A set of
classes and interfaces can play this role, by means of abstract syntax.
>There were many systems that used that kind of language binding in the 1970s
>and 1980s, typically with COBOL and PL/I: the Codasyl DML was based entirely
>on this model. When relational systems became popular in the mid 80s
>embedded SQL was used with C, but it was overtaken in the market by
>"call-level interfaces" that supplied DML statements as strings.
>
>
>
People do not like to deal with proper language extensions. Pizza has
algebraic types for Java, hardly anybody seems to have noticed.
>It's not entirely clear to me why the call-level interfaces won the battle.
>I suspect it has something to do with the inconvenience of preprocessing;
>perhaps something to do with the difficulty of different standards groups
>agreeing on a hybrid language (I seem to remember great political battles
>with the Ada/SQL binding); and something to do with the sheer variety of
>programming languages that people want to use. Another reason for the
>success of call-level interfaces, notably ODBC, was the desire to avoid
>committing a client application to a particular vendor's database product at
>compile time: there are many benefits in late binding.
>
>
>
With algebraic types, it would be possible to build up an abstract
syntax tree, which would be passed to the driver before shipping to the
database.
In Pizza (or Haskell or ocaml or Scala) one would do like this:
Var b = Var();
Var authors = Var();
FLOWR(
For( b, Doc("books.xml").descOrSelf("bib:book"),
/* for $b in doc("books.xml") // bib:book */
Let( authors, b.descOrSelf("bib:author") ),
/* let $authors = b // bib:author */
_,
_,
Return(
element("result"),
Sequence( b.child("bib:title"), authors )
) /* return <result>{ $b/bib:title, $authors }</result> */
)
Using abstract syntax is like using the Command design pattern. methods
like descOrSelf(..) would construct a new command instance from an old.
It might look ugly (and loose popularity), but at the very least you
eliminate a range of syntax errors while retaining advantages of late
binding, vendor-neutrality etc. Also, this solution is only partial, as
things like element names are still strings, not constants - that would
depend on data binding.
One can add a library which parses strings, and provide a "call-level
interface" facade. (I would not call anything that exchanges raw strings
an interface, it is rather a decorated IO channel). But there are enough
developers who cannot take hunting for syntax errors popping up at
runtime any longer, and depriving them of a real interface (like JDBC)
seems like a mistake to me.
>As a matter of interest, there is continuous pressure (which the WGs have so
>far resisted) for a dynamic XPath binding to XSLT - that is, the ability for
>an XSLT stylesheet to construct XPath expressions from run-time strings. I
>am not in the slightest flabbergasted by this requirement, it seems very
>natural to me.
>
>
>
But if the interface depends only on abstract syntax (what is certainly
possible in Java), the programmer can parse strings himself if he really
likes to, and deal with exceptions that arise during parsing.
If one deals with strings I believe most database drivers would ship the
query string "as is" to the database (because you would not like to
duplicate the code to parse the query strings, because strings are
already serialized, cause the DB has to handle strings anyway, etc).
This causes least work for the driver developer, and most work for the
application developer, who has to deal with errors popping up at
runtime, and testing syntax of his queries depends on having a running
DBMS to answer the queries.
>In the case of a Java/XQuery binding, defining the query language as a
>sublanguage of Java seems hardly viable. The place for that is in some kind
>of higher level tool, e.g. a JSP tag library, or an XML pipeline processing
>language.
>
>
>
I agree that changing something by adding to Java syntax is an approach
with severe shortcomings (and probably not the goal of JSR225), and that
higher-level languages and tools can find more elegant solutions.
<advertising href="http://scala.epfl.ch";>Luckily with Scala there is at
least one higher-level language that can interface with Java
code.</advertising>
But using only strings is clearly the worst one can do. If an
application is dealing with XML, it can *at the very least* pass trees
to the database. interface. Xquery even has an XML syntax.
cheers,
Burak
|
