Re: PHP_FALIAS()

From: Date: Mon, 10 Sep 2007 19:10:09 +0000
Subject: Re: PHP_FALIAS()
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-32201@lists.php.net to get a copy of this message
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 10, 2007, at 14:08:43, Hartmut Holzgraefe wrote:
BuildSmart wrote:
Thanks for the response, OK I think I can manage that with ease, what I'm contemplating to do is create a mysql_alias extension that aliases the mysql extension functions to the mysqli equivalents
uh .... PHP_FALIAS() would only work for functions having exactly the same parameter signature ... so it would only work with a very minor subset of the mysql/mysqli functions (if at all). For a lot of functions the signature changed so that the database handle is now the first parmeter instead of the last, and even for those that look similar you have to take into account that mysqli relies on objects (even for the procedural style functions) where ext/mysql is all about resources, not objects. There is also the concept of the default connection in ext/mysql that does not exist in ext/mysqli at all so that can't be emulated by just aliasing functions either ...
Yes, I realize that not everything will be directly mappable without some kind of helper functions and this includes creating some default fallback settings.
While a ext/mysql -> ext/mysqli compatibility wrapper might make sense it is way more effort to create one, and if you really want to go that way i'd recommend that you do a proof-of-concept implementation using PHP code first before starting the effort to wrap it up in a C extension.
Always a good approach and well worth adhering to as it would allow for validation of the concept before implementation. Perhaps the best approach would be to mimic the ext/mysql functions and feed them to ext/mysqli function rather than aliasing them directly but maybe a performance trade-off might be encountered as a result. On some cursory tests I've found that the ext/mysqli extension functions seem to execute faster, while not a significant leap in time based on a single DB query .472ms as compared to .279ms, over a period of time this can amount to a significant savings if the site is query intensive.
That aside i don't think that it would make much sense to create such a wrapper, ext/mysql being deprecated says that we won't add any new features to it. There are no plans to remove it though and any serious security issues or possible incompatibilities with newer libmysqlclient versions will still be fixed.
My main goal is to increase performance, I think that working from a proof of concept based on a small subset of minimum required functions might be the first order of business to determine if any loss would be experienced and if so then going further would be a waste of time. As well, what works in a controlled environment doesn't always reflect a production environment so the whole project might be nothing more than an exercise in futility but if I don't examine the possibilities I'll never know.
--Hartmut Holzgraefe, Principal Support Engineer
- -- Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFG5ZaR0hzWbkf0eKgRAn18AKDAxJPq0AzxhNyfaYvStPnTAsoRmwCfbcjX YaMSOcjOvtP6KGAbt3oitFQ= =HsJl -----END PGP SIGNATURE-----

« previous php.internals (#32201) next »