Everything

php

PHP_FALIAS()

php.internals

Dale Walsj

18 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've seen several examples of PHP_FALIAS within a single module, I'm
wondering if it's possible to have one module with aliases
referencing functions in another module?

- -- Dale
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFG4m0P0hzWbkf0eKgRAmlXAKChGWEIl+Hz9uOFVFv76qddNH0T5wCeIllB
VsN5vneLwIMBXwBTSEzSbH0=
=fw4n
-----END PGP SIGNATURE-----

Marcus Börger

18 years ago

Hello BuildSmart,

If you have the correct includes in place, sure.

marcus

Saturday, September 8, 2007, 11:36:15 AM, you wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> I've seen several examples of PHP_FALIAS within a single module, I'm
> wondering if it's possible to have one module with aliases
> referencing functions in another module?

> - -- Dale
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (Darwin)

> iD8DBQFG4m0P0hzWbkf0eKgRAmlXAKChGWEIl+Hz9uOFVFv76qddNH0T5wCeIllB
> VsN5vneLwIMBXwBTSEzSbH0=
> =fw4n
> -----END PGP SIGNATURE-----

Best regards,
Marcus

Dale Walsj

18 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Sep 10, 2007, at 08:53:29, Marcus Boerger wrote:

> Hello BuildSmart,
>
>   If you have the correct includes in place, sure.
>
> marcus

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 since
a lot of scripts and packages are already dependent on the mysql
extension but it's been deprecated (so I've been informed) and I was
thinking of a simple method to allow the dropping of the mysql
extension in favor of the mysqli extension without having to rewrite
existing scripts and packages.

Since you claims it's possible to alias an external extensions
functions I guess it's just a matter of getting the includes worked
out and what headers need to be loaded in the faking module.

This will probably require a little finessing but shouldn't be too
difficult or complicated.

>
> Saturday, September 8, 2007, 11:36:15 AM, you wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>
>> I've seen several examples of PHP_FALIAS within a single module, I'm
>> wondering if it's possible to have one module with aliases
>> referencing functions in another module?
>
>> - -- Dale
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.2.2 (Darwin)
>
>> iD8DBQFG4m0P0hzWbkf0eKgRAmlXAKChGWEIl+Hz9uOFVFv76qddNH0T5wCeIllB
>> VsN5vneLwIMBXwBTSEzSbH0=
>> =fw4n
>> -----END PGP SIGNATURE-----
>
>
>
>
> Best regards,
>  Marcus

- -- Dale

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFG5Uc00hzWbkf0eKgRAomHAKCegTASJWoqwHi+szmDwiXU82wVdQCgqzBT
uf2junm3kDfwnOZzDTnCKOI=
=+07f
-----END PGP SIGNATURE-----

David Coallier

18 years ago

On 9/10/07, BuildSmart <buildsmart@daleenterprise.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Sep 10, 2007, at 08:53:29, Marcus Boerger wrote:
>
> > Hello BuildSmart,
> >
> >   If you have the correct includes in place, sure.
> >
> > marcus
>
> 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 since
> a lot of scripts and packages are already dependent on the mysql
> extension but it's been deprecated (so I've been informed) and I was
> thinking of a simple method to allow the dropping of the mysql
> extension in favor of the mysqli extension without having to rewrite
> existing scripts and packages.
>
> Since you claims it's possible to alias an external extensions
> functions I guess it's just a matter of getting the includes worked
> out and what headers need to be loaded in the faking module.
>
> This will probably require a little finessing but shouldn't be too
> difficult or complicated.
>

Actually if you look at zend_API.h which contains ZEND_FALIAS
(PHP_FALIAS /main/php.h) you'll notice that as long as the includes
are done, it's quite trivial to do :)

Good luck,

> >
> > Saturday, September 8, 2007, 11:36:15 AM, you wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >
> >> I've seen several examples of PHP_FALIAS within a single module, I'm
> >> wondering if it's possible to have one module with aliases
> >> referencing functions in another module?
> >
> >> - -- Dale
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.2.2 (Darwin)
> >
> >> iD8DBQFG4m0P0hzWbkf0eKgRAmlXAKChGWEIl+Hz9uOFVFv76qddNH0T5wCeIllB
> >> VsN5vneLwIMBXwBTSEzSbH0=
> >> =fw4n
> >> -----END PGP SIGNATURE-----
> >
> >
> >
> >
> > Best regards,
> >  Marcus
>
> - -- Dale
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (Darwin)
>
> iD8DBQFG5Uc00hzWbkf0eKgRAomHAKCegTASJWoqwHi+szmDwiXU82wVdQCgqzBT
> uf2junm3kDfwnOZzDTnCKOI=
> =+07f
> -----END PGP SIGNATURE-----
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
David Coallier,
Founder & Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18

Johannes Schlueter

18 years ago

Hi,

On Monday 10 September 2007 03:31:32 pm 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 since
> a lot of scripts and packages are already dependent on the mysql
> extension but it's been deprecated (so I've been informed) and I was
> thinking of a simple method to allow the dropping of the mysql
> extension in favor of the mysqli extension without having to rewrite
> existing scripts and packages.

I, personally, don't think it's such a good idea to replace the dependency of
the mysql extension with an dependency on two extensions, mysql_alias+mysqli,
and also you should keep in mind that ext/mysql and ext/mysqli might work a
bit different in a few minor places.

For going from ext/mysql to ext/mysqli the MySQL guys have some conversion
script somewhere on their site afaik.

And a last thought: If you need a wrapper wrapping ext/mysql API over mysqli
I'd do it in PHP since distributing PHP code is way simpler than distributing
some extension and the performance lost can be ignored since most time is
still lost while doing communication with the database server. (the few
exceptions usually can do other optimizations giving better results or simply
use no wrapper)

johannes

--
Johannes Schlüter
http://schlueters.de

Hartmut Holzgraefe

18 years ago

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 ...

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.

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.

--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html

Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140

Dale Walsj

18 years ago

-----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-----

Adam Maccabee Trachtenberg

18 years ago

On Mon, 10 Sep 2007, BuildSmart wrote:

> 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.

Based on my experiences, if you're keeping to the procedural
interface, aren't doing crazy things with default links, and not
adding in anything new, the API changes are relatively small and
self-contained.

So, I would suggest people take the minimal amount of time to migrate
through using search and replace and minor syntax updates. It solves
the speed issue and sets you up to take advantage of MySQLi-only
features.

However, if you feel the need to do this for various reasons, I would
start here:

http://old.coggeshall.org/show_source.php?filename=mysql2mysqli.php

-adam

--
adam@trachtenberg.com | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!

Dale Walsj

18 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Sep 10, 2007, at 16:15:35, Adam Maccabee Trachtenberg wrote:

> On Mon, 10 Sep 2007, BuildSmart wrote:
>
>> 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.
>
> Based on my experiences, if you're keeping to the procedural
> interface, aren't doing crazy things with default links, and not
> adding in anything new, the API changes are relatively small and
> self-contained.
>
> So, I would suggest people take the minimal amount of time to migrate
> through using search and replace and minor syntax updates. It solves
> the speed issue and sets you up to take advantage of MySQLi-only
> features.
>
> However, if you feel the need to do this for various reasons, I would
> start here:
>
> http://old.coggeshall.org/show_source.php?filename=mysql2mysqli.php

Kewl, the majority of the POC already done, thanks.

>
> -adam

- -- Dale


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFG5bTg0hzWbkf0eKgRAi+ZAKDAWWa+HrEACbZj079MzRzlOipaawCgk4JH
yCCOKVFrkd9zqqkQBIvRDXM=
=nWIJ
-----END PGP SIGNATURE-----

Dale Walsj

18 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Sep 10, 2007, at 16:15:35, Adam Maccabee Trachtenberg wrote:

> On Mon, 10 Sep 2007, BuildSmart wrote:
>
>> 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.
>
> Based on my experiences, if you're keeping to the procedural
> interface, aren't doing crazy things with default links, and not
> adding in anything new, the API changes are relatively small and
> self-contained.
>
> So, I would suggest people take the minimal amount of time to migrate
> through using search and replace and minor syntax updates. It solves
> the speed issue and sets you up to take advantage of MySQLi-only
> features.
>
> However, if you feel the need to do this for various reasons, I would
> start here:
>
> http://old.coggeshall.org/show_source.php?filename=mysql2mysqli.php

Well, cursory testing proved successful and the general concept is
good so I moved to the next phase and made an extension based on the
script code but the added execution time defeated the purpose since
no time savings was achieved, actually it ended up being a little
slower so the only advantage was that the ext/mysqli extension could
be used without script modification.

The only way to keep the time savings would be to modify the ext/
mysqli extension which is essentially just combining ext/mysql and
ext/mysqli extensions which in itself wont provide any significant
benefits other than making the code harder to maintain.

TIme to give up and move on.

>
> -adam

- -- Dale


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFG5pJE0hzWbkf0eKgRAntNAKDGJ3oX8LRpk0XP8vrq6DNRpbhcDgCfWymU
zbQ03KKHZ7htIdSxBqYH4C8=
=m6+i
-----END PGP SIGNATURE-----