PHP database interfaces: PDO or PDBC?
In a comment to my posting on MySQL 5.0 getting bug free, Lukas Smith wants MySQL to promote PDO.
I had a chat with Georg Richter about this. He tells me he is working on a PDBC (”JDBC for PHP”) specification and prototype which allows people
a) to write database independent programs
b) to migrate easily from or to other applications (e.g. Java)
c) write powerful applications
d) to reuse existing code written in Java or C++.
Georg’s goal for the upcoming OSDBCON (and PHP Conference) is to find some people from other OS DB projects which like the idea and would like to contribute to PDBC.
So, if you want to be involved in PDBC, talk to Georg at the OS DB Conference 8-9 November 2005 in Frankfurt (where I will also give a presentation on “10 Years of MySQL: Building a Commercial Open Source Software Company”).
September 28th, 2005 at 0:08
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.
September 28th, 2005 at 11:46
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.
October 7th, 2005 at 12:17
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.
October 7th, 2005 at 16:51
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.