PDO + The Role of PHP + SQLite - Am I missing something?
in [Databases]
|
From: "Lawrance Shepstone" on 11 May 2010 07:19 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-January/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
From: Niel Archer on 11 May 2010 11:44 > 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-January/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
|
Pages: 1 Prev: MySQL Wildcard Next: Extending my login - not sure how to add my code block in |