Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Early Draft Review: XQuery for Java (JSR 225)
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
