On 08/08/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote: > Larry Garfield wrote: > > On Tuesday 07 August 2007, Lester Caine wrote: > >> Lester Caine wrote: > >>> Christopher Jones wrote: > >>>> Lester Caine wrote: > >>>>> I keep being told that the PDO drivers can be extended to include all > >>>>> of the things already available in the native driver, but the second > >>>>> you do that they become incompatible, so in addition to the PDO > >>>>> driver you need to also run the native driver simply to provide the > >>>>> areas NOT covered by PDO. We need a generic framework that addresses > >>>>> the real problems not one that creates an artificial lowest common > >>>>> denominator strangle hold :( PDO could evolve into that, but not with > >>>>> it's current restrictions. > >>>> Can you list the current restrictions as you see them? > >>> Actually the very first one has been addressed and has nothing to do > >>> with PDO. Up until recently is was essential to provide backwards > >>> compatibility with PHP4 and all of the projects I currently work with > >>> WOULD still install on PHP4. Although *I* never used it in production, > >>> the continued support meant that there was a large base that insisted on > >>> retaining it. So ADOdb's continued underlying support for PHP4 is useful > >>> and until there are a higher percentage of PHP5 users than PHP4 - PDO > >>> takes second place as it is not available on a large number of hosts? > > > > As you noted, this one is no longer an issue[1][2]. > > > > [1] http://gophp5.org/ > > [2] http://www.php.net/index.php#2007-07-13-1 > > > >>> The next problem builds on the above one. From the PDO manual "PDO does > >>> not provide a database abstraction; it doesn't rewrite SQL or emulate > >>> missing features. You should use a full-blown abstraction layer if you > >>> need that facility." ADOdb will run PDO drivers quite happily, but on > >>> current information the performance of the PDO drivers is slower than > >>> using the same native driver. So given a choice the native one is > >>> preferable and currently essential for PHP4 support. > > > > I've seen some of the numbers posted, at least as far as MySQL. As Ilia has > > noted before, MySQL's native prepared statement support sucks all on its > > own. > > It's faster to use PDO's internal implementation. > > > > That said, you need to make a direct comparison. PDO, especially with > > prepared statements, does a lot more processing than a direct > > implementation. > > That takes a lot more cycles than just passing mysql_query() a string. > > However, just passing mysql_query() a string is not secure. You need to > > implement your own escaping mechanism on top of it (because trusting > > yourself > > to always call mysql_real_escape_string() in every instance is a recipe for > > disaster). That takes even more cycles, because it's happening in PHP > > rather > > than in C. > > > > As a case in point, I recently tried to implement a PDO layer for Drupal as > > an > > alternative to the mysql_* implementation. Drupal currently implements its > > own prepared statements in user-space, using a printf()-like syntax and > > preg_replace_callback(). When I replaced that with PDO's own prepared > > statements, I found performance was about a wash[3]. On the other hand we > > do > > get type-safe prepared statements and simpler code, so we're planning to > > move > > to PDO in Drupal 7 at this point. > > > > [3] http://drupal.org/node/134580 > > > >>> NEITHER of the above are restricted to Firebird and apply equally to all > >>> databases, but they are the main reason to date that no one has had the > >>> inclination to fix the pdo_firebird driver as it's deployment potential > >>> is currently limited. > > > > My knowledge and experience with Firebird is nil, so I cannot say anything > > useful for that. > > > >>> The internals of PDO restrict things to using SQL access to the > >>> database. While it will probably be said that the database should ONLY > >>> provide SQL access to everything, Firebird has a services interface > >>> which is used for such things as backup, user management, and the event > >>> handler. How should all those be handled if they are moved to the PDO > >>> driver? > > > > Are you talking about Firebird-specific features, or all non-SQL-standard > > queries? As far as I know PDO allows arbitrary strings as queries so > > SQL-esque database-specific stuff should still work. Wez, is that not the > > case? > > > I make no claim of being a PDO expert either, and my database experience is > > 98% MySQL, but the above is my experience and reading so far with it. PDO's > > main selling points are 1) A fully OO API and 2) A common API for all > > databases. By nature, it does result in "lowest common denominator" issues > > as well, including potentially performance. If you're aiming for > > cross-database compatibility, I'd recommend it over rolling your own. If > > you > > can guarantee that you'll only need <insert some database here>, then the > > specific driver may be a better option in some cases. YMMV and so forth. > > No, the idea is that there is a common set of methods and a common > infrastructure to support those. However every driver is free to > implement driver specific things and prefix those methods with the > driver name. So in theory all the RDBMS specific goodies in all of the > native drivers can also go into PDO.
Right. And Wez posted this (partially in reply to Lester's almost identical hysterics at that time) on this very list ages ago (http://news.php.net/php.internals/14937 - Feb 14, 2005, to be exact): BEGIN QUOTE: Drivers are free(*) to implement driver specific methods on the PDO and PDOStatement objects, provided they are "namespaced" eg: $db->mysqlDoSomething() would be a mysql driver specific feature. More generic attributes can be accessed or set via the get/setAttribute methods. (*) while they are "free" to do so, it's better to discuss the feature first to see if it can be made into a more generic feature of PDO itself END QUOTE So can we _please_ move on, Lester? If someone who cares about Firebird wants to beef up the PDO_Firebird driver with all kinds of Firebird-specific features, the answer is still the same as it was almost two and a half years ago: the PHP project humbly awaits that person's patch. -- Dan Scott Laurentian University -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
