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 http://avalon.apache.org/apps/apps/db/index.html (no idea about the status, no builds seem available) There's Jakarta Commons SQL http://jakarta.apache.org/commons/sandbox/sql/index.html (not quite the same) Certainly, OJB needs to take care of such things as well (while it's not their main point) http://db.apache.org/ojb/ Obviously, Torque has that as well http://db.apache.org/torque/ 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. Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
