cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: big ESQL performance problem - this one's weird
Date Wed, 05 Mar 2003 10:09:58 GMT
On 05.Mar.2003 -- 09:43 AM, Torsten Curdt wrote:
> Leszek Gawron wrote:
> >On ??ro, mar 05, 2003 at 01:16:26 +0100, Torsten Curdt wrote:
> >
> >>So you think cocoon should fix all the bugs that software vendor X
> >>refuses to fix? come on!
> >
> >I have the "pervasive case" in my mind and was reffering to that. I think 
> >it's
> >not even a bug (that awful performance) but the way they have designed the 
> >SQL
> >layer on Btrieve DB - you have to use it in a specific way to get your 
> >results
> >quite fast or you won't get them at all. It's a matter of cocoon if it will
> >support the database or not.
> ...well, so you ask for a per database behaviour of esql.
> Doable but not done yet.
> Hm... Chris, what do you think about creating a full featured database 
> abstraction layer?

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.

There's Avalon DB for example (no idea about the
status, no builds seem available)

There's Jakarta Commons SQL (not quite
the same)

Certainly, OJB needs to take care of such things as well (while it's
not their main point)

Obviously, Torque has that as well

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.

Adding back plain Statements and loading the decision on the developer
is good. Doing it automatically depending on the DBMS is a problem,
though, because we would have to escape and convert parameters.

C h r i s t i a n       H a u l
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

View raw message