On 16/11/12 17:03, Rasmus Lerdorf wrote: > So, I am curious, why are you waiting on us for this? Is it because > ext/mysql does everything you need and you simply have no need for any > of the new and obviously better features in mysqli? I would have thought > you would have switched to mysqli years ago if it was available and only > used ext/mysql as a desperation fallback if that was all that was available. > > Not a criticism, but a curiosity. This is part of why this is going to > be a very painful process no matter which path we take. It is an > extension which works just fine and will continue to work for people. I > wish we could come up with a better carrot for getting people to migrate > versus just hitting them with a stick which most people here seem to > advocate. > > -Rasmus What are those benefits that mean everyone needs to move to mysqli? I was making myself the opposite question :)
The only reference was about the cost of maingaining it at the beginning of this thread, but now Johannes Schlüter said (16 Nov 2012 08:38:19 +0200) that it doesn't really need work to maintain it. So, you have a project using a php-userland wrapper around ext/mysql. It takes care of getting the variables properly escaped (yes, passing the appropiate db connection), adds the table prefixes, it may even do fancy things like generating different SQL for the different db types (no, just using PDO doesn't solve that). What does mysqli add to it? Prepared statements? The db processing may be faster with them, but you now have two roundtrips, so its net effect is arguably. mysql_stmt_bind_param is tedious (compare that with python where you just pass the list of values). You will need call_user_func to call mysqli_stmt_bind_result inside a wrapper. You still need to manually mangle the sql for things like adding a common prefix to the tables (you can't bind a value there). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
