Hi List,

It seems that I'm a little confused (and thus frustrated) with PDO in
general, and especially when it comes to PECL php_sqlite3.

I understand that PDO is a data-access abstraction layer, and as one, is
really good. However, the way I see it, is that PDO should just be an added
extra, and not the stock-standard for data-access. It should simply wrap a
set of low-level libraries that are still exposed to developers should they
choose not to use PDO (for whatever reason). While this is true for most
databases, how long will it be until the current low-level libraries like
PECL php_mysql and PECL php_mysqli are no longer maintained, and we are
forced to use PDO?

This can be seen with the PECL php_sqlite extension, which is not maintained
anymore. I understand why it's not maintained anymore, because there is PECL
php_sqlite3. The problem here is that PECL php_sqlite3 only offers an OOP
approach, and no procedural approach. So, for developers that want to
develop their own data abstraction layers (access or model), they have to
now wrap the PECL  php_sqlite3 SQLite3 set of classes. This makes the entire
layer slower, more complex, and therefore more error-prone. Most developers
are forced to use PDO for SQLite 3 access (due to PHP versions or other
reasons), which is still a set of classes that bloat any further abstraction
they may choose to develop.

The following posting shows the unnecessary confusion on this topic:


Confusion like this has led to the development of an SQLite 3 procedural

http://php-sqlite3.sourceforge.net/pmwiki/pmwiki.php - not to be confused
with the current PECL php_sqlite3 (dash vs underscore)

But surely if the PECL php_sqlite3 extension has already been developed and
included in the default distributions of PHP, it must be possible to include
a procedural interface as well? How long will it be before we are forced to
use bloated objects for everything we need to do in PHP? Isn't that the
great thing about PHP? That at its core it's a great, fast scripting engine
with a few core libraries, and then everything else is implemented through

I fully understand the power that OOP offers, and I understand that is a
vital part to the maturity of PHP as a *language*, but I just can't see why
the speed and elegance of interfacing with low-level extensions using
procedural methods should be completely dropped. For me, as a developer, I
have enjoyed the freedom (of choice and ability) that PHP offers - the
ability to create the next best data-abstraction layer, or MVC framework.
Why should these important innovations be made more difficult by forcing the
use of bloated libraries - simply because they adhere to strict OOP best
practices, and ultimately force developers to create their own extensions,
when it takes less time and work to expose the low-level API like the one
already wrapped by PECL php_sqlite3.

Wouldn't it provide developers with more opportunity if the current PECL
php_sqlite3 extension was dropped in favour of PDO, and replaced with a more
low-level library like PECL php_sqlite for version 3 databases? That way
developers would be able to develop their own access and model abstraction
layers with good performance should they choose to, or make use of PDO
should they need something a little more robust and feature-full? The Zend
Framework's Zend_DB* objects provide both data-access-abstraction and
data-model-abstraction, but still have to wrap PDO for data-access.

The problem with developing another custom extension is that hosting
providers only use stable releases of PHP and PECL, which makes it near
impossible to have a custom extension enabled in a shared hosting
environment. Not to mention, again, that the notion of developing a custom
extension to expose functionality that already exists (like that already
wrapped by PECL php-sqlite3), is insane.

Am I missing something?

Where do I get involved to help improve the situation?

All the best,
"Any intelligent fool can make things bigger and more complex...
It takes a touch of genius - and a lot of courage to move in the
opposite direction." - Albert Einstein

PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to