Re: DB_Light

lustig@acsu.buffalo.edu wrote: > > OK, so I've been thinking, through all of this conversation about a new > DB abstraction layer. Now, it's really nice to have a full-featured, > totally abstracted abstraction layer... however, some applications don't > need all of the "extras" like the DB-specific queries to do things like > get all of the tables, or to get all of the rows for a table and stick > them into an array -- those types of things could be done on a > case-by-case basis, and when you're working on an application that'll > get tons of hits all the time (like a message board or a high-profile > website) where the abstraction of the SQL can be left up to you and all > that you need is a very simple API to connect and do queries, it is a > speed problem when you're including ~75 kb (AKA a ***lot***) of files > with every pageload... if someone chopped out a lot of the "extra" > features, for a streamlined version of PEAR::DB, perhaps it could be a > new package, "DB_Light" (or something), a faster PEAR::DB. These are > some of the things that I think should be kept in something like that: > > query() > fetchInto() -- no fetchRow(), because it's extra > isError() > quote() > > There's probably more... that's all that I can think of off the top of > my head right now (besides that I have to go to class in a few minutes)... If the purpose is to make the code load faster, I think there are better options. But right now I feel that the right focus for PEAR DB would be to become feature complete. Then we can start discussing speed-ups and dynamic-loading architecture. One piece at a time, or it'll never see the light of day. - Stig