Published 2004-10-22 18:13:42

Ever since PDO was proposed, there have been warm fuzzy feeling about it's iminent arrival. I hate to say, though I fear it could be the biggest mistake PHP ever makes.! (well I guess among the worse).

That's not a lightweight statement, and I'll fire of the disclaimers, before I go any further.
  • I'm working on an alternative at present.
  • I know the authors of PDO personally, and I probably owe them a drink for dissing the work.
  • From what I've seen of the code in PDO, it's pretty damn good.

So what you may ask is so wrong with it?

The major issues I have with PDO are
  • Reuse, recycle...

    When there was at least 2 capable, cross platform database libraries available. Rather than examine if they where a feasible option, it was decided to go off and start from scratch.

    Having spent quite a time working with libgda, probably the best library available to do this, It has a 5 year head start, fully tested, and is considerably more feature rich than PDO will ever be.

    PDO seems to be slowly gaining backends, however, It's a long way from having as many as libgda. And for each of the features missing in PDO, It will take time to ensure they are enabled in all the backends, let alone fully tested.

  • Copying C is not always a good idea..

    The worst features of PDO is variable binding (similar to pointers). This is what could be regarded as 'minefield programming'. In some of the worst wars in history, army's laid mines all over stratigic borders, so that the oposing army would be delayed in crossing. What happened after the war was a tragic travasty, the abandoned minefields started injuring innocent civilians.

    The way variable binding is done in PDO mimics this behaviour, while it achieves the goal of making updating rows relatively simple, It has the significant downside that it makes code unpredictable, splattering variables, which if changed may update a database, without making it clear and simple that this may occur. This whole issue should have been dealt with by using objects to represent database rows, and only make these usable as 'updateables' (see the introduction to DataObjects) which is exactly how DBDO was designed.

  • Cool features dont always make great features.

    Iterators where introduced with much fanfare in PHP5, using foreach on an object that implements the iterator methods, and result in a fetch operation on every foreach. The simple example below illustrates the crux of the problem. (and I've already seen people pastebin iterator code, and you really are making wild guess as to the intent of the code)

    Without sensible variable names, this rather confusing code easily evolves into complete jiberish..
    foreach ($pdoresult as $row) {
    ....?? is $row an object/array/or something else. ??

    compared to the clarity below

    while ($do->fetch()) {
    $data = $do->toArray();

    While I believe you can still use PDO without using iterators, They do lie at the heart of the problem. I dont know if it was an off-the-cuf remark, but It appears that PDO started as a proof of concept for using iterators on Databases, and as it evolved became a limited Database abstraction layer, which leads into the last issue.

  • Design by evolution, at the beginning or end.

    I dont think I've ever come away and designed an interface correctly the first time, by now DBDO has a long history.

    • Started off as Midgard's Data Model emulation in Midgard Lite
    • dboo, was an improved version, introducing query building from object vars, primary key knowledge
    • DB_DataObject, introduced a generator, simple data type knowledge, PEAR DB backend, Joins, and alot more.
    • DBDO takes DataObjects as a base, removes alot of cruft that has built up, and at the same time introduces extensive datatype support, lazy fetching.
This now leaves DBDO at a stage where most of the documenation is already done (as part of DataObjects).

In comparison, since PDO does not appear to have a history, It's first generation API has not had a chance to be picked apart by thousands of users. It lacks documenation (although that apparently will be fixed soon.)

I'm sure there are some valid reasons why DBDO could not stand up as the next generation Database library for PHP5, but I wonder seriously if those are less significant than PDO's.
  • Win32 Support
    After considerable work over the last month, this is pretty much solved. (Although I only bothered building mysql/postgres for win32, to continue the process should be pretty simple.). Given this work already, the amount of effort to make it 'enterprise ready', is pretty minimal now.
  • Too many libraries?
    Libgda has a midsized dependancy list, although this is not that major compared to libxml2, which is now part of the standard distribution. Currently DBDO needs
    • libgda (obviously)
    • libglib
    • libgmodule
    • libgobject
    • libgthread (maybe not necessary)
    • libxml2 (used by PHP's xml extension already)
    • libxlst (used by PHP's xlst extension already)
    • iconv (used by PHP already)

Not sure if this blog will change the fact, but by not using libgda, I think PHP is missing a huge opportunity to stand on the shoulders of giants, and get a world class Database backend, with a limited effort.

Mentioned By: : PHP: PDO Functions - Manual ( referals) : PHP: PDO - Manual ( referals) : php pdo ( referals) : AKBK home - Smoking toooooo much PHP - PDO - Why it should not be part of core PHP! ( referals) : php pdo performance ( referals) : PHP: Fonctions PDO - Manual ( referals) : pdo performance ( referals) : december ( referals) : node/21 ( referals) : pdo num_rows ( referals) : april ( referals) : pdo mysql_result ( referals) : php pdo examples ( referals) : php __toarray ( referals) : mysql_result pdo ( referals) : pdo mysql_num_rows ( referals) : php pdo example ( referals) : -> db layer ( referals) : pdowrapper - Google Code ( referals) : mysql_num_rows pdo ( referals)


my comments
hopefully objective ;-)

- reuse/recycle: on the whole, I agree. In the specific case of libgda, IMO, the dependency list is a bit too heavy considering that most of the features provided by those dependencies already have a PHP internals equivalent. In a sense, we're not really re-using that infrastructure with libgda, but duplicating it.

- copying C: I agree that bound parameters can lead to magic code. There are two things to keep in mind: a good coding style (with comments) is the best remedy for code that might be considered magic.
And secondly, the use of bound parameters is optional, and there is a non-magic variation if prefer.

- iterators: they aren't even implemented yet, and they certainly are *not* the core feature of PDO. Again, their use, once implemented, will be optional.

PDO is certainly young, but it is designed to work with the PHP internals, rather than around them, which is something I view as a major plus point for PDO, and a bit of a minus point against any other existing db library.

My opinion on libgda is that the dependency list is a bit high, and the problems you mentioned with win32 have me concerned that it will be painful to install on *nix (note that I've never seen a system with it installed, and couldn't name an application that uses libgda), and perhaps not be functional on win32. I feel that this is enough of a reason to not have an extension that uses libgda in the core distro.

On that topic, I personally don't mind if PDO goes into the core or not, and to be honest, I would be happy to have PDO stay in PECL, as it will make it easier to upgrade outside of the regular PHP release cycle. This same idea applies to any/all PHP extensions IMO.
#0 - Wez Furlong ( Link) on 2004-10-22 23:11:32 Delete Comment
Well, although I tend to agree with the bound magic thing... It's the argument of giving power to the experienced users vs. preventing newbie suicide. I mean if you think people would shoot themselves with goto, how much do you think they'll shoot themselves with this??

I think interators are VERY useful...but not the way you show them used

why would you want to iterate the connection? why are you storing the result with the connection? you'd want to iterate the result

$result = $do->query();
foreach($result as $row)

and what if you wanted two results at once?

$result1 = $do->query();
$result2 = $do->query();
foreach($result1 as $row)
foreach($result2 as $row)

optimally you'd do
$result = $do->query($query, return type);
foreach($result as $row)

Although the question of whether this is better implemented in userland is always up for discussion.
#1 - Rora ( Link) on 2004-10-23 00:07:38 Delete Comment
Why would it need to be either or? From my perspective, DBDO will be great when I want to have database abstraction (software I may distribute and want to gain adoption). However, in my work at my day job I am not really looking for abstraction; PDO seems to provide consistency without abstraction.

#2 - jaxn ( Link) on 2004-10-23 09:41:06 Delete Comment
foreach ($pdoresult as $row) {
....?? is $row an object/array/or something else. ??

That's a great example for stupid programming optimization.

I'm using PHP now for a long time, and there are a lot of shortcuts I don't use, as long as they are no a performance issue.

I preffere to writhe 2 or 4 lines more code which is perhaps not that nerdy, if it's more readable.
#3 - Jonas ( Link) on 2004-10-23 19:54:04 Delete Comment
I think alan has one good point. When should we wrap a third party library (thereby accepting a number of deps) and when should we write from scratch. How many addition LOC are we talking here? How happy are you with your windows solution? Will the experience we different for windows users (performance, stability ..)?

His other points go back into the discussion of how much should we protect the unwashed masses form themselves. For iterators we have already made a decision. For variable binding we havent specifically, but I dont see this as a biggy.
#4 - Lukas ( Link) on 2004-10-23 20:53:48 Delete Comment
Comment on iterators:
while I never used this feature, I'm wondering..

Something like type casting would make things more explicit no ?:
foreach($result as (array)$row) {}

Another solution would be to use a method result:
foreach($result->getArrayIterator() as $row) {}

The first example would need to introduce a new __toArray() magic method, like __toString().
(which btw is not castable, except with print and echo, probably because of BC)

#5 - zimba ( Link) on 2004-10-24 00:11:57 Delete Comment
Speaking of mistakes, writing about something that will be new to many of your readers without defining it, seems like one.

PDO = Personal Digital Ortographer?

PDO = Pungent Dog Odor?

PDO = Prehistoric Dinosaur Objects?

PDO = Please Define O . . . ?
#6 - Some Guy ( Link) on 2004-10-26 05:15:00 Delete Comment
Another Mistake:

Ortographer --> Orthographer
#7 - Some Guy ( Link) on 2004-10-26 05:15:59 Delete Comment
#8 - S ( Link) on 2004-10-30 02:19:22 Delete Comment
There is a __toArray() magic method
#9 - ( Link) on 2004-10-31 19:37:39 Delete Comment
Have to agree with Wez on this.

PDO looks like a geat idea!
#10 - Hugh Jass ( Link) on 2005-07-08 15:03:28 Delete Comment
You have some valid points. While I do agree that the maturity of preexisting solutions is desireable, I do not agree that PDO needs anything more than what it already has.

Your criticisms of data binding and pointers, however, pisses me off. Personally, I find goto statements to be proof of Satan's existence. How many coders actually use goto statements except when playing a practical joke? They aren't a problem. Even if they were, I still think goto statements should be in every language.

Pointers exist in C because there is no other way in such a low-level language. PHP is higher level and offers a multitude of features in the language itself. Pointers aren't necessary, but I want them anyway. I want every available language construct to be at my disposal. Good and bad.

I'm tired of puritanical language nazis telling me what I can and cannot use. I like pointers. They don't give me problems. If people can't grasp them, don't use them. Provide warnings. DO NOT dumb down a language because the masses are dumb.
#11 - Pestilence ( Link) on 2005-07-28 03:41:06 Delete Comment
This is not what we need...
My issue with PDO is completely different from yours. What use is another database abstraction layer? I know that the developers say it is not another DB abstraction layer like pear DB, but it is! And it doesn't prevent your from using implmentation-specific SQL! (For example, with PDO, I can still use MySQL's DATE_FORMAT and INTERVAL and what not).

What PHP *REALLY* needs, IMO, is a data access object interface. There are some pretty smart developers around the PHP circle, and I'm sure that they could tackle the problem of writing a generic data access module (like the Pear::DB_DataObject project) to be integrated into PHP core. This would be FAR FAR FAR more useful than another abstraction layer like Pear::DB.
#12 - taylor ( Link) on 2005-08-05 05:57:04 Delete Comment
Service Data Objects (SDO) Examples
Philippe Jausions: do you know some more examples of using SDO, other then at and ?
#14 - Koistya `Navin [] ( Link) on 2005-09-02 19:07:41 Delete Comment
where are mysql_Result like function for PDO? and mysql_num_rows, or sqlite functions... PDO don't have num_rows or result! :( oh no... it won't work
#15 - roberto spadim ( Link) on 2005-11-25 21:25:29 Delete Comment
Web Architect
In reply to Taylor about the fact that PDO is just another abstration layer, he got it right. But isn't that always the case in PHP ? First you would program a function in PHP yourself, then you release the code, then everybody use it then it becomes a part of the core code. I don't think the PHP team was trying to bypass PEAR::DB but re-use the good idea and adapt it to the new features available in PHP5. When you code enterprise level application, you need a flexible solution. The error handling in PEAR::DB was not very good, neither is the one from DataObject ... Integrating the exception mechanism is one really good reason to switch, although I know a lot of you guys would do a die(mysql_error()) in the middle of your code, which is not possible on large scaled, security needy projects.

Another great advantage is that PDO is coded in c, not in PHP, which makes it much faster than a PHP framework.

Last point, about the example:

foreach ($pdoresult as $row) {
....?? is $row an object/array/or something else. ??

of course you don't know. PHP has no type !

$myarray = array();
// Code to initialize $myarray
foreach($myarray as $value)
//Can you tell what $value is ??? Nop
this issue is inherant to the PHP language, not PDO.

+ you can always choose the implementation you want.

PHP must continue to grow in that direction and become more and more like other prefered entreprise language like Java. I congratulate the PHP team for the fantastic work they are doing, keep on moving up !
#16 - Matthieu - Eb-Cubes Inc. ( Link) on 2005-12-02 04:21:20 Delete Comment
PDO for MySQL is usless
for MySQL I would rather use mysqli extension!
#17 - Psih ( Link) on 2006-01-12 23:56:54 Delete Comment
PDO Useless
As soon as I saw the "magic variables" crap, I knew. I will never use software written by people who think this is acceptable AND JUSTIFY IT.

This means variable binding is unusable. What is the use of a database access layer with no variable binding ? None.

For how a database interface should be done, check the Python interface (esp. psycopg2). Period.
#18 - Peufeu ( Link) on 2007-05-10 23:21:58 Delete Comment
PDO is still useless
Well... It is nearly 4(!) years from first comment for this article. We use oci8 extension at this time and we still use oci8 now... The one of the reasons is that PDO_OCI does not support PDO::PARAM_STMT as IN OUT bind variable in any driver and we havily use stored procedures with recordsets. So PDO was and still useless toy in our case... Actually pitty
#19 - gotscha ( Link) on 2008-02-20 20:15:22 Delete Comment

Add Your Comment

Follow us on