cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@dff.st>
Subject Re: big ESQL performance problem - this one's weird
Date Wed, 05 Mar 2003 10:46:49 GMT
<snip/>

> You're joking. At least in book, full featured would entail providing
> a SQL parser and talking to the server native protocol. Certainly not
> as part of Cocoon.

Well, I did not mean it *that* full featured way ;)
Though it might be worth to have a look into all that is available...

I thought more in direction of a capabilities "repository" (sorry, I 
just don't have good term for it yet) that hides some of those details 
than you usually wanna think about. We could make it a component that 
can be accessed from the database modules as well as from esql.

<snip/>

> IOW, yes, it is a cool idea and would help many people a great deal if
> done correctly. But it's too big to be a part of Cocoon.

aggree

> Adding back plain Statements and loading the decision on the developer
> is good.

hm... I would not call it "good"

> Doing it automatically depending on the DBMS is a problem,
> though, because we would have to escape and convert parameters.

It's not that easy. "0 parameters" does not necessarily mean "use 
Statement over PreparedStatement" - that's the point. So either we make 
it configurable (adding a esql tag or attribute) or other people might 
complain.
--
Torsten


Mime
View raw message