Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32201
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daleenterprise.com from 67.78.11.229 cause and error)
In-Reply-To: <46E5882B.7010909@mysql.com>
References: <B5DA574D-EC5A-4CE2-AA94-EFD926AB23F2@daleenterprise.com> <199717507.20070910145329@marcus-boerger.de> <64047417-3838-4E20-B767-110266B9F4A0@daleenterprise.com> <46E5882B.7010909@mysql.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <AEDEB3B4-E349-45DF-B86F-0DCB61DB07F4@daleenterprise.com>
Cc: Marcus Boerger <helly@php.net>,
	PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Date: Mon, 10 Sep 2007 15:10:09 -0400
To: Hartmut Holzgraefe <hartmut@mysql.com>
MTA-Interface: amavisd-new-2.3.3 (2005-08-22) + Maia Mailguard 1.1.0 at daleenterprise.com
Subject: Re: [PHP-DEV] PHP_FALIAS()
From: buildsmart@daleenterprise.com (BuildSmart)

-----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-----