Comments on: PHP database interfaces: PDO or PDBC? http://blogs.mysql.com/kaj/2005/09/27/php-database-interfaces-pdo-or-pdbc/ MySQL, FOSS, Sun and Community plus a dash of running and mountaineering Sun, 12 Oct 2008 12:46:57 +0000 http://wordpress.org/?v=2.6.1 By: Andrey Hristov http://blogs.mysql.com/kaj/2005/09/27/php-database-interfaces-pdo-or-pdbc/#comment-20 Andrey Hristov Fri, 07 Oct 2005 13:51:51 +0000 http://www.planetmysql.org/kaj/?p=10#comment-20 Hi Lukas, I will separate my answer in 2 parts. 1) mysqli had problems with LOBs during fetch which were addressed months ago. There is "problem" with the max_length not updated by default by libmysql because this hurts performance. In this case the max length of a column has to be allocated, e.g. for MEDIUMBLOB it's 16M. I have patched ext/mysqli before to sense whethere there are BLOBS (BLOB and MEDIUMBLOB) and activate the update of max_length in the MYSQL_BIND structure. This makes the queries slow but does not eat a lot of memory (if there are at max 2000bytes in a MEDIUMBLOB only 2000bytes will be malloced instead of 16M). However, to do get this effect and not explosive results one has to follow specific order of function calls - this is unfortunately undocumented because I have experience with the PHP doc system. Related PHP bug is http://bugs.php.net/bug.php?id=32013 The let update of max_length to work one has to use buffered queries (store_result()) and not unbuffered queries, because in the latter case there is no way to get the right max_length (the server won't send such info). The right order is prepare() execute() store_result() bind_result() What's important is that store_result() is executed before bind_result() otherwise the memory saving won't work. Otherwise, from working point of view it does not matter the order these 2 functions(methods) are called. 2)Going back to the issue you have. I looked at the MDB2 source and saw you experience a problem by executing a query which binds LOBs are params. Unfortunately, we are not aware of a problem and we would appreciate more information given as feedback to fix the problem you experience. Hi Lukas,
I will separate my answer in 2 parts.
1) mysqli had problems with LOBs during fetch which were addressed months ago. There is “problem” with the max_length not updated by default by libmysql because this hurts performance. In this case the max length of a column has to be allocated, e.g. for MEDIUMBLOB it’s 16M. I have patched ext/mysqli before to sense whethere there are
BLOBS (BLOB and MEDIUMBLOB) and activate the update of max_length in the MYSQL_BIND structure. This
makes the queries slow but does not eat a lot of memory (if there are at max 2000bytes in a MEDIUMBLOB only 2000bytes will be malloced instead of 16M). However, to do get this
effect and not explosive results one has to follow specific order of function calls - this is unfortunately undocumented because I have experience with the PHP doc system.
Related PHP bug is http://bugs.php.net/bug.php?id=32013
The let update of max_length to work one has to use buffered queries (store_result()) and not unbuffered queries, because in the latter case there is no way to get the right max_length (the server won’t send such info). The right order is
prepare()
execute()
store_result()
bind_result()

What’s important is that store_result() is executed before bind_result() otherwise the memory saving won’t work. Otherwise, from working point of view it does not matter the
order these 2 functions(methods) are called.

2)Going back to the issue you have. I looked at the MDB2 source and saw you experience a problem by executing a query which binds LOBs are params. Unfortunately, we are not aware of a problem and we would appreciate more information given as feedback to fix the problem you experience.

]]> By: Lukas http://blogs.mysql.com/kaj/2005/09/27/php-database-interfaces-pdo-or-pdbc/#comment-19 Lukas Fri, 07 Oct 2005 09:17:56 +0000 http://www.planetmysql.org/kaj/?p=10#comment-19 While on the subject of MySQL php APIs. A blog post of mine (http://pooteeweet.org/blog/243) that got syndicated on planetmysql and planetphp about LOB support in mysqli went unanswered. I think this gives some indication of the level of adoption. While on the subject of MySQL php APIs. A blog post of mine (http://pooteeweet.org/blog/243) that got syndicated on planetmysql and planetphp about LOB support in mysqli went unanswered. I think this gives some indication of the level of adoption.

]]> By: Lukas http://blogs.mysql.com/kaj/2005/09/27/php-database-interfaces-pdo-or-pdbc/#comment-12 Lukas Wed, 28 Sep 2005 08:46:38 +0000 http://www.planetmysql.org/kaj/?p=10#comment-12 PDO was always planned as a thin layer as a first step. The idea was that higher level things could be build ontop of PDO. I originally planned to move over PEAR::MDB2 (which features alot of portability features like datatype abstraction, schema reading and management etc.) over to the PDO API to make it possible to provide PDO based drivers while remaining compatible with PHP4. However the work involved in making the necessary changes were just too large so once I finish up MDB2 its time to start a PDO based alternative .. be it in userland or be it in C. PDO was always planned as a thin layer as a first step. The idea was that higher level things could be build ontop of PDO. I originally planned to move over PEAR::MDB2 (which features alot of portability features like datatype abstraction, schema reading and management etc.) over to the PDO API to make it possible to provide PDO based drivers while remaining compatible with PHP4. However the work involved in making the necessary changes were just too large so once I finish up MDB2 its time to start a PDO based alternative .. be it in userland or be it in C.

]]> By: Hermann van der Loy http://blogs.mysql.com/kaj/2005/09/27/php-database-interfaces-pdo-or-pdbc/#comment-11 Hermann van der Loy Tue, 27 Sep 2005 21:08:05 +0000 http://www.planetmysql.org/kaj/?p=10#comment-11 From my personal experience in 2 of my projects where I tried to use PDO, I don't see any benefit of using PDO. I don't have to deal with different function names (which is sometimes a pita), but all the differences between the various RDBMS we have to support is still in my code. That makes it hard to maintain. PDBC (I assume it's a JDBC pendant) implemented in PHP would cover most of the problems in one function call ( JDBC 3.0 specs cover mostly everything!), and it would be much more userfriendly. Rewriting an existing PHP application in PDBC might be a lot of work, but for new projects it would be really cool. From my personal experience in 2 of my projects where I tried to use PDO, I don’t see any benefit of using PDO. I don’t have to deal with different function names (which is sometimes a pita), but all the differences between the various RDBMS we have to support is still in my code. That makes it hard to maintain.
PDBC (I assume it’s a JDBC pendant) implemented in PHP would cover most of the problems in one function call ( JDBC 3.0 specs cover mostly everything!), and it would be much more userfriendly.

Rewriting an existing PHP application in PDBC might be a lot of work, but for new projects it would be really cool.

]]>