PDO + The Role of PHP + SQLite - Am I missing something?

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:

http://lists.macosforge.org/pipermail/macports-users/2009-Ja nuary/013658.htm
l

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

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
extensions?

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,
Lawrance.
____________________________________________________________ ____
"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

Re: PDO + The Role of PHP + SQLite - Am I missing something?

> 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:
>
> http://lists.macosforge.org/pipermail/macports-users/2009-Ja nuary/013658.htm
> l

Most of the confusion there is based on misunderstandings, I would say.

> Confusion like this has led to the development of an SQLite 3 procedural
> extension:
>
> 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?

When no procedural developers step up and write the extensions. No point
complaining that some developers with an interest in an OOP
implementation of an OOP library took the time to do the work.

>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
> extensions?

> 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

Something of an exaggeration. As the sqlite3 library has an OOP API, it's
more likely a procedural interface would be adding the bloat, if any.

>- 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.

Not true, as noted above, SQLite3 uses an OOP API at low-level

> 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 PECL extension is NOT the current implementation of the extension.
The PDO/PDO_Sqlite extension/driver are separate to the Sqlite3
extension.
I'm not familiar with ZF's way of doing things, but I doubt is *has* to
use PDO. This is more likely a choice they made.

> 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.

Agreed. So take your pick of PDO/PDO_sqlite or just SQLite3 extensions.
Both are enabled in PHP 5.3.0 by default, and should be in 5.2 builds
also.

> Am I missing something?

PDO is not needed to access SQLite3. Use the SQLite3 extension; which is
installed by default with PHP 5.3.0.
As noted on the installation instructions for the extension:

Note: This extension was briefly a PECL extension but that version is
only recommended for experimental use.

So avoid it like the plague and stick with the main extension ;-)

> Where do I get involved to help improve the situation?
>
> All the best,
> Lawrance.
> ____________________________________________________________ ____
> "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

--
Niel Archer
niel.archer (at) blueyonder.co.uk



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