Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
Dan Scott wrote: 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 NOTE the (*) - I'm TRYING to reopen the discussion on generic things like transaction handling. Simply bolting driver specific solutions back into each different driver in a different way is pointless? We have those drivers already? The extra's are less of a problem than missing CORE facilities :( 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. The MAIN problem here is that a number of the things I'm talking about are NOT Firebird/Interbase specific, and ARE already managed via ADOdb, but they are currently disabled if you use the PDO driver *IN* ADOdb. The general consensus then was that PDO WOULD get round to addressing these areas. In two and a half years has anything been done yet? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
Lester Caine wrote: Dan Scott wrote: 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 NOTE the (*) - I'm TRYING to reopen the discussion on generic things like transaction handling. Simply bolting driver specific solutions back into each different driver in a different way is pointless? We have those drivers already? The extra's are less of a problem than missing CORE facilities :( Ok, yes this is indeed an issue. PDO does not support nested transactions. No other RDBMS that I am aware of supports this and for all I know it does not work in the ibase driver either. Atleast we tried to use it in MDB2 and never got it to work. Ask Lorenzo for details on this. However again it does not prevent firebird specific methods for handling nested transactions, which an abstraction layer author may then choose to use in a firebird driver. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
Larry Garfield wrote: 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 That nicely summaries some of the aspects of moving to PDO from the user side. You are thinking that you will have to support PHP4 and non-PDO drivers until 2012 :) The main thing I see there is 'raw' SQL. Loading the variables directly into the script, rather than simply binding them as params. I have yet to work out a way of converting some of my dynamically generated SQL into a format that will work with PDO - on any database. I've only ever used ADOdb and that handles ALL of the parameterizing of things transparently. The other problem of cause is length of table and field names and reserved words. Adding Oracle and MsSQL to the mix, working with raw upper case table and field names and 31 character name limit introduces a few extra things to consider over and above just adding PDO to Drupal ;) 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 only point I was making here is the one you have covered - we need to support PHP4 for some time yet - which ever database you are using :( 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? There are other interfaces other than just the 'SQL' one for talking to but then the database industry are working from the other end to come in line with the standards. Perhaps another one for 2012. 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. TODAY - I think that is right. I'm not as negative about PDO as people seem to think! It is just that TODAY there is a packaged working solution to MY problem, which many other people are using as well so there is no need to spend time 'rolling your own' version of PDO that mirrors those facilities? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
Lester Caine wrote: The main thing I see there is 'raw' SQL. Loading the variables directly into the script, rather than simply binding them as params. I have yet to work out a way of converting some of my dynamically generated SQL into a format that will work with PDO - on any database. I've only ever used ADOdb and that handles ALL of the parameterizing of things transparently. I have no clue what type of dynamically generated SQL you are talking about. Are you talking about being able to dynamically stick identifiers into placeholders? This is simply not possible if you are using native prepared statements. If you emulate them, yes you can, but then you can might as well use sprintf() with quote() (maybe with a wrapper). The other problem of cause is length of table and field names and reserved words. Adding Oracle and MsSQL to the mix, working with raw upper case table and field names and 31 character name limit introduces a few extra things to consider over and above just adding PDO to Drupal ;) PDO handles some of those, but as said tons of times before, its not an abstraction layer, its an API unifier. There are PDO based layers like Doctrine, that give you all the convinience of ADODB (and more ..). They do however require that the underlying PDO driver is solid. At any rate .. why bother with PDO when there are native extensions? The point of PDO was not only end user focused, it was also the idea to one day make it less effort to add new features to all the RDBMS extensions (for example unicode .. that being said I keep hearing that PDO HEAD is totally out of sync). It also makes it a lot easier to add a new RDBMS extension. Now if we stick with maintaining the current non PDO extensions, then you must realize that we are maintaining a lot of redundant code, which is based on one of the oldest extensions (ext/mysql). Since we do not have infinite development resources, it would be for the better of any of the supported RDBMS if it would get its PDO driver up to the same level as the old extension. As more and more of our userbase is moving to PHP5 this hopefully will become more and more interesting. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
Lukas Kahwe Smith wrote: Lester Caine wrote: Dan Scott wrote: 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 NOTE the (*) - I'm TRYING to reopen the discussion on generic things like transaction handling. Simply bolting driver specific solutions back into each different driver in a different way is pointless? We have those drivers already? The extra's are less of a problem than missing CORE facilities :( Ok, yes this is indeed an issue. PDO does not support nested transactions. No other RDBMS that I am aware of supports this and for all I know it does not work in the ibase driver either. Atleast we tried to use it in MDB2 and never got it to work. Ask Lorenzo for details on this. However again it does not prevent firebird specific methods for handling nested transactions, which an abstraction layer author may then choose to use in a firebird driver. You are going beyond where I've got to ;) I'm just looking to be able to select auto commit on or off, and switch transaction modes. Something which many 'proper' databases support but which I do note that other generic drivers only make this available via the connect string, something which explains why I get different results when changing from Firebird within ADOdb. I'm simply used to wrapping an update in it's own transaction, which can be rolled back and then reworked if required. I will be honest here - never using other databases *IN* PHP other than via ADOdb, I had not appreciated that many of the native drivers simply don't provide access to facilities that I KNOW exist in those databases themselves! This probably explains why I get such blank responses when trying to get things sorted. ibase_trans allows me to set up a package of work on the database, set up the type of transaction ( something that I KNOW Oracle, DB2 and MsSQL internally support ). I can build a set of report results using 'concurrency' isolation level get the results and post them back to the database in a second transaction, or I can wait on other activity completing before posting the changes. I think that I had not appreciated that the Oracle, DB2 and MsSQL drivers have to create a new connection for a new transaction :( ( I'll answer the point on the other post separately - at least *I* am beginning to understand how restrictive the PHP interface is to other database users and that explains why there have been such differences of opinion in the past ;) ) -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
Following on Lukas Kahwe Smith wrote: Lester Caine wrote: The main thing I see there is 'raw' SQL. Loading the variables directly into the script, rather than simply binding them as params. I have yet to work out a way of converting some of my dynamically generated SQL into a format that will work with PDO - on any database. I've only ever used ADOdb and that handles ALL of the parameterizing of things transparently. I have no clue what type of dynamically generated SQL you are talking about. Are you talking about being able to dynamically stick identifiers into placeholders? This is simply not possible if you are using native prepared statements. If you emulate them, yes you can, but then you can might as well use sprintf() with quote() (maybe with a wrapper). OK this is a key difference between MySQL and other databases - at least looking at the raw drivers. Firebird ( and PostgreSQL ) can use parameters to handle the transfer of values to the query. From pg_query_params manual - The primary advantage of pg_query_params() over pg_query() is that parameter values may be separated from the query string, thus avoiding the need for tedious and error-prone quoting and escaping. Most projects I work with, build an array of values to be processed, and then just create a simple SQL query to pass the array to the database. PDO does wrap this quite nicely, except that BLOB's can only be passed as raw content? The ability to just pass a BLOB ID means that you only access that part of a large blob that you need. And most database engines would benefit from being able to handle BLOB elements independent of the general fetch. Rather than duplicating and processing several hundred 'k' text blobs, you just pass the link to the original? The other problem of cause is length of table and field names and reserved words. Adding Oracle and MsSQL to the mix, working with raw upper case table and field names and 31 character name limit introduces a few extra things to consider over and above just adding PDO to Drupal ;) PDO handles some of those, but as said tons of times before, its not an abstraction layer, its an API unifier. There are PDO based layers like Doctrine, that give you all the convinience of ADODB (and more ..). They do however require that the underlying PDO driver is solid. At any rate .. why bother with PDO when there are native extensions? The point of PDO was not only end user focused, it was also the idea to one day make it less effort to add new features to all the RDBMS extensions (for example unicode .. that being said I keep hearing that PDO HEAD is totally out of sync). It also makes it a lot easier to add a new RDBMS extension. The IDEA is still good. It just needs the core tidying up a little more before it becomes totally practical. Now if we stick with maintaining the current non PDO extensions, then you must realize that we are maintaining a lot of redundant code, which is based on one of the oldest extensions (ext/mysql). Since we do not have infinite development resources, it would be for the better of any of the supported RDBMS if it would get its PDO driver up to the same level as the old extension. As more and more of our userbase is moving to PHP5 this hopefully will become more and more interesting. Having finally got to the point where PHP4 *IS* being end of lifed, then one of the major stumbling blocks HAS been removed. That is why I *AM* now coming back to this - after 2 years - and trying to nail down some of the remaining problems. I have had to be careful even with the Firebird driver to ensure that only functions available in PHP4 are used in ADOdb, but it will be nice to be able to say - that version of project X is the last which will support PHP4! NOW we can get on and start looking for PHP6 and proper Unicode support - Firebird can run DIFFERENT character collations in each field something else that still needs the native driver to handle ;) -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
Lester Caine wrote: Following on Lukas Kahwe Smith wrote: Lester Caine wrote: The main thing I see there is 'raw' SQL. Loading the variables directly into the script, rather than simply binding them as params. I have yet to work out a way of converting some of my dynamically generated SQL into a format that will work with PDO - on any database. I've only ever used ADOdb and that handles ALL of the parameterizing of things transparently. I have no clue what type of dynamically generated SQL you are talking about. Are you talking about being able to dynamically stick identifiers into placeholders? This is simply not possible if you are using native prepared statements. If you emulate them, yes you can, but then you can might as well use sprintf() with quote() (maybe with a wrapper). OK this is a key difference between MySQL and other databases - at least looking at the raw drivers. Firebird ( and PostgreSQL ) can use parameters to handle the transfer of values to the query. From pg_query_params manual - The primary advantage of pg_query_params() over pg_query() is that parameter values may be separated from the query string, thus avoiding the need for tedious and error-prone quoting and escaping. But these parameters may only be literals not identifiers. The only difference in placeholder support is if the placeholders are named (pgsql, oracle etc.) or not (db2, mysql etc.). PDO (and MDB2, Doctrine etc. for that matter) support both the named and unnamed in all drivers. SELECT * FROM ?; // does not work The reason is technical, the idea behind prepared statements is to have the database be able to parse and plan the query once. Without identifiers this would not be possible. PDO does wrap this quite nicely, except that BLOB's can only be passed as raw content? The ability to just pass a BLOB ID means that you only access that part of a large blob that you need. And most database engines would benefit from being able to handle BLOB elements independent of the general fetch. Rather than duplicating and processing several hundred 'k' text blobs, you just pass the link to the original? Blobs in PDO are implemented via the stream API, so its not only raw content. Adding support for blob id's would be a good idea if its not yet supported. Speaking of which, another area where PDO standards to reduce duplicate efforts is documentation, which is still a bit lacking atm (where is the new Dan?). regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
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? 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. 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. 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? PDO provides a basic transaction control that hides the transaction modes. It can't handle retaining the context of the transaction following a commit or roll back, or selection a more appropriate transaction mode? CONCURRENCY for reports at a fixed time point over COMMITTED to handle changes made in other transactions. How does one switch between a 'wait' and 'nowait' transaction? The one that prompted this discussion. How do you return a simple handle to a BLOB object so that you DON'T have to download the whole blob. It can be useful to hold the blob id so that you only access a sub set of the data from the blob object. This seems to be missing in PDO? HAVING to maintain PHP4 support has meant that I have not gone into PDO with a fine tooth comb, and most of my understanding of the problems of PDO is based on what has been said elsewhere, but at present I can't see how some of these fundamental facilities provided by the php_interbase driver would be mirrored in PDO. I stand to be corrected, and perhaps when PHP4 has died THEN the supposed advantage of PDO may be a more attractive development path? But at present there is simply no incentive to move over :( Things went quiet :( Is there anything in my above list this is NOT correct? I do stand to be corrected about PDO, but at present I can't see how to get around the limitations even IF the pdo_firebird driver was functional. And I see some of these restrictions applying to other database engines as well? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
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? PDO provides a basic transaction control that hides the transaction modes. It can't handle retaining the context of the transaction following a commit or roll back, or selection a more appropriate transaction mode? CONCURRENCY for reports at a fixed time point over COMMITTED to handle changes made in other transactions. How does one switch between a 'wait' and 'nowait' transaction? The one that prompted this discussion. How do you return a simple handle to a BLOB object so that you DON'T have to download the whole blob. It can be useful to hold the blob id so that you only access a sub set of the data from the blob object. This seems to be missing in PDO? HAVING to maintain PHP4 support has meant that I have not gone into PDO with a fine tooth comb, and most of my understanding of the problems of PDO is based on what has been said elsewhere, but at
Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
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. regards Lukas
Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
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
