MySQL AB invited me to Frankfurt to talk about their PHP native driver project. While I am not much of a C-hacker, I do know database API's and users preferences in them quite well from my work on MDB2. As such my job was to present a wish list for features. Do note that this is a wish list and any features I mention in this blog post are not yet in any definitive plan. Aside from that, I also took it upon me to make sure that whatever we do, we try to keep the API as clear and simple as possible.

Anyways, at first I was wondering if the chance for a speed increase was really worth MySQL AB throwing developers at this. I am also not that concerned about the license of libmysql. With the FLOSS exception everything seems more or less ok. So why go through all the trouble? A lot of the wish lists items could easily be implemented on top of libmysql.

Now in the first presentation in the meeting Georg went over the architecture. And there it hit me. As Georg was showing which parts of libmysql would be replaced by PHP infrastructure. For example the new driver would use the PHP memory manager. This would help in doing away with some needless data pushing. But it also means that suddenly MySQL would also comply with PHP's memory limits. Now for something really cool. The new driver would use the PHP streams API, which should make it possible to add in streams wrapper and filters to check on the communication between PHP and your MySQL server. How cool is that?

I looks like connection persistence will also make a reappearance, though this time the user environment should get cleaned up at the end of a request. This effectively circumvents the main issue I see with them. The other issue is of course that if you don't use a threaded web server setup, is that you end up creating one connection per worker process. This obviously requires fine tuning, but its less of an issue imho than getting locking issues due to open transactions not getting rolled back automatically.

Another feature that seems likely to get implemented is a TTL based query cache. This one should even work with prepared statements from day one. Profiling (for example on a request basis) is also likely to be among the features added. As you can see from the wish list, we discussed a wide range of topics. Georg, Ulf and Andrey are working out a time table for which features will be ready for the tentative first release in Q1 2007. Expect some blogging from them in the coming days.

Pretty exciting stuff if you ask me!

perhaps (even sure) i'm missing something, but even if that looks exciting, what about PDO and this driver ? using a pdo driver really has some benefits , wouldn't that be even more great if this new driver was a sort of pdo_mysql_extended ?
that is just a quick thought and first reaction in reading your post, i'm very curious to read your thought about that.

Yes, the plan is to support both mysqli and pdo with this new driver starting with PHP6. The work will start with mysqli, since this simply has the most features implemented already, so its simply a more complete test case for the start. In the end the idea is that you cam compile mysqli or pdo either against the old libmysql or the new shiny native driver.

thanks for the clarification! that make sense for me now.
so that means the PHP project will have to choose which lib to build against for windows user ? or provide both ?

This is too early to tell. I guess the main deciding factor will be stability. This is something we are hoping to proof my a huge number of test cases. However, we are not only talking about written test cases but hopefully also application level test cases. But most importantly it will be a question of the community participating in this effort. We are talking about replacing one of the most extensively used libraries in PHP after all!