Re[2]: [PHP-PEAR] PHPLib and Pear merge

[email protected] (Maxim Derkachev) Fri, 9 Mar 2001 16:07:21 +0300
Newsgroups php.pear
Organization Symbol Plus Publishing Ltd.
Message-ID <[email protected]>
Hello Chuck,

Wednesday, March 07, 2001, 7:22:27 PM, you wrote:

>> Could you elaborate upon this limitation with a simple example of what you
>> can't do with phplib and what you can do with PEAR:DB?

CH> If I want to nest sql queries, such that each inner query depends on a row of 
CH> the outer query, I can do this in pear, because running a new query doesn't 
CH> wipe away the current result set. But with phplib, I'd need to loop through the 
CH> entire outer query, store the results somewhere, and then do all of the inner 
CH> queries.

Valid point, but you are not telling the whole truth.
You know that you can initialize another DB_Sql object within the
loop. It would act like a PEAR::DB result object. Since PHP reuses
connections, the script actually won't do any extra connect()s to
execute the nested query. DB_SQL is light and even in this condition it should
run faster then the huge PEAR::DB structure. So you indeed *can* do
the thing easily.
PEAR::DB, instead do have some crucial limitations in its current
state. E.g. why don't bother to include support for accessing number
of rows affected by the insert/update/delete query? It is supported by
almost any mainstream database available. Why don't bother to count
number of rows returned by select? It is one of most needed things in
web development. It is natively supported by many databases (e.g. Mysql, Postgres),
and can be easily emulated (or, in any case, the method could return
'not supported' for performance reasons) for those that don't support this.
PEAR::DB eats much more resources then DB_Sql and can't afford those simple
things which could be done in half an hour or less?

-- 
Best regards,
Maxim Derkachev mailto:[email protected]
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
http://www.Books.Ru -- All Books of Russia