1be4
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
$do->query(); 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.
20
Previous Topic
