[
Lists Home |
Date Index |
Thread Index
]
Bob Foster wrote:
>
> 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.
>
Well, you can also plug queries together like legos - orthodox or not,
it is not the same as ripping apart and glueing together strings.
> 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.
>
I agree it feels clumsy at first. But then, in an application one builds
queries in a dedicated package, and one will appreciate resuing certain
"typed" building blocks over the typical cut-and-paste madness.
Do you remember what happens with your SQL statements and queries if a
column was added or renamed after you wrote your program ?
You will have to scan your entire program for occurrences of this table,
check whether there was a SELECT * FROM or an INSERT INTO which does not
work with the old set of column names. A bit of OO abstraction could
have certainly helped also JDBC.
Evangelism aside, it is not an either-or question. Some library built on
top of the string-based API (like Squiggle) is not likely to implement
all functionality you get with XQuery. Rather, some users (if
knowledgeable of the benefit) will reimplement their own things on top
of the string-based API *over and over again*. For me this seems like a
weak design (and here it becomes a technical judgement).
Instead, focussing on trees, and offering a string-based API for
"compatibility" reasons, seems better since it keeps all doors open -
hence a good design.
cheers,
Burak
|
