Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:4584
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <7BE0F4A5D7AED2119B7500A0C94C58AC3D6D87@DELLSERVER>
To: internals@lists.php.net
Date: Thu, 25 Sep 2003 16:51:18 +0200
MIME-Version: 1.0
Content-Type: text/plain
Subject: RE: [PHP-DEV]  differences in the RDBMS ext API's
From: M.Boeren@guidance.nl (Marc Boeren)


Hi,

> IMO there are some problems with the dbx extension:
> 
> - it is a wrapper for PHP modules instead for the underlying 
> database API (therefore slower)

True, but this makes for a lot less build-headaches: dbx has no
build-dependencies

> - you cannot rely on it if you depend on an ISP that does not support 
> this extension

True for any non-standard extension (however, for this case I usually make a
simple, pure-php wrapper with the dbx_function names mapped directly to the
database). I would like to see more ISPs include dbx of course, and since it
builds without any dependencies and has just a small footprint it should be
really easy to do. 

> - it does not include a C API that would be useful for custom PHP 
> modules to access a database

I have successfully used the dbx extension from within another
(C++)-extension, perhaps not as clean as I would have with an API, but ok.

> - it does not include an OOP API

OOP-ish :-)

> My dream is a "full featured" SQL extension completely replacing all 
> other database modules, fast, flexible, build-in by default, 
> recommended to be the best way to access databases in PHP.

Yeah, I would have liked that too ;-). I do like the way this is solved in
Python with its DB-API, however they have great namespace/module
resolution...

> Just my two cents....

Appreciated.

Cheerio, Marc.