Lists Home |
Date Index |
Burak Emir wrote:
> 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
> 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.
Yes, it was pointed out earlier that I misunderstood your position. Sorry.
The main advantage of your proposal, OOP orthodoxy aside, seems to be in
preventing syntactically incorrect queries. Given that this is an API to
XQuery, however, the user probably already has some knowledge of XQuery
syntax...and has the benefit of being able to test the queries with
specific values in a standalone XQuery implementation. On the con side,
building up expressions using individual For, Where, etc. classes is
certainly going to be clumsier.
AFAIK, one could implement what you propose on top of the JSR 225
proposal (when evaluated, the objects would simply output a string), but
I don't think I'd want to use it. That's not a technical judgement,
though; just a matter of taste.