XQJ (JSR 225)

[David A. Lee]

 From this description (from one who uses JDBC daily) this maps fairly 
directly to the JDBC concepts

JDBC:                         XQJ
Statement                    XQExpression
PreparedStatement      XQPreparedExpression


So on that sense I would agree it is "intuitive to users of jdbc".
But that said, JDBC is kinda weird as I never understood why the 
"Statement" actually doesnt hold the SQL, you have to pass it in to execute,
so why would anyone use it instead of PreparedStatement ?  But there is 
subtle reasons sometimes programming convenience, and sometimes 
efficiencies depending on your DB where you can get a performance hit by 
doing a separate prepare.

I would say this does "seem intuitive" to at least one user of JDBC I 
can see why they'd go that route.
Knowing JDBC I might be able to figure out XQJ mabye 10 minutes faster 
by assuming 'its the same thing but with an X".

-David






David A. Lee
http://x-query.com/mailman/listinfo/talk  
http://www.calldei.com
http://www.xmlsh.org
812-482-5224



Michael Kay wrote:
>>   BTW, does someone knows why there is a difference between 
>> an "expression" object that is actually used to evaluate 
>> (possibly several different if I am right) XQuery expressions 
>> and a "prepared expression" that really represents a 
>> (compiled) XQuery expression?
>>
>>   At first glance, it seems rather confusing to me.
>>     
>
>
> It's a very strange design. It's worth noting that neither XQExpression nor
> XQPreparedExpression is thread-safe - both extend XQDynamicContext and
> therefore hold context information which is different for each evaluation of
> the expression.
>
> The difference between them is that XQPreparedExpression contains a compiled
> expression or query, whereas XQExpression merely holds the dynamic context
> for executing an expression or query - despite its name, the expression to
> be evaluated is not held in the XQExpression object, but is always supplied
> dynamically. 
>
> Whenever I complained about the design (or even the nomenclature) I was told
> it would all seem completely intuitive to people who know JDBC. I've no idea
> whether that's true; I'm quite sure it's not a good justification.
>
> Unless you need the portability, I recommend Saxon's s9api interface. It's
> also probably more efficient. A weird consequence of the close() mechanism
> in XQJ, which was presumably designed to allow resources to be released
> early, is that Saxon has to maintain links between a connection and all the
> objects created under that connection, and this stops those resources being
> garbage collected.
>
> Regards,
>
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay 
>
> _______________________________________________
> http://x-query.com/mailman/listinfo/talk
> http://x-query.com/mailman/listinfo/talk
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://x-query.com/pipermail/talk/attachments/20090625/312332a1/attachment.htm