[
Lists Home |
Date Index |
Thread Index
]
Bob,
Bob Foster wrote:
> Burak Emir wrote:
>
>> There are tons of things that one would like to do with an XQuery
>> expression in Java, not just ship them to the database. In some
>> sense, the discussion about analyzers, optimizers, debuggers all
>> makes a case for a having a high-level model of queries.
>
>
> Your argument seems to boil down to the idea that compilation will
> always have certain advantages over interpretation, a widely held
> view. People who lived through the history of embedded SQL are
> unlikely to be convinced, as you are just echoing the arguments made
> decades ago in the SQL context - and string APIs by and large won out
> - in part because they can proliferate most rapidly in a wide variety
> of host languages. But even in the
Again: I am not making a case for embedded SQL. I am argueing for a
different representation of the query when passing it to the interface.
A class XQueryExpression that I can build up from other
XQueryExpressions if you will.
I did not and I do not believe that one can compile every query (this
would fail to build queries at runtime), I said the plain vanilla Java
compiler and the plain vanilla class-based Java type system should be
able to check your code that constructs XQueryExpressions, i.e. by
having concrete subclasses for For, Where, OrderedBy, XPath expressions...
> abstract, the counterpoint is that interpretation will always have
> certain advantages over compilation. For example, a query engine is by
> nature an interpreter, no matter what you put in front of it. Engines
> that require time-consuming optimization passes tend not to succeed
> commercially, so providers learn to deliver good performance in real
> time. The best argument for compilation is strong typing and early
> error detection, but the relative value of this vs. good, continuous
> testing is still debated in circles that favor interpreted languages.
> And strong typing doesn't address the real problem at all - that the
> database schema can change, invalidating existing programs that use
> it. Recompilation and/or retesting of all such programs is required in
> either case.
Sure.
>
> Last but not least, JSR 225 presents a proposal for a string-based
> API. Where is the proposal for an API requiring language changes?
>
Yeah, see it's only string based. What happens, if I have a fixed way of
building queries ? I get a string from a textfield, and I am searching
for all books by that guy. PreparedStatement seems to do the trick. But
what if I want to *nest* this query in another one ? I have to use
string concatenation. Instead, it would be nice just to call the
constructor of some XQueryExpression, and pass the existing instance of
XQueryExpression as an argument.
It's still interpreted, it's just another representation, one that uses
objects instead of strings.
cheers,
Burak
|
