Hi all,
I'm actually putting my head into ext/mysqlnd and I noticed weird
things about its API.
As you should know, ext/mysqlnd is a replacement for libmysql, that
is, all our 3 MySQL-related extensions may use it, and it is done by
default for 5.4 branch.
However, I've been surprised that ext/mysqlnd expose its API through
ext/mysqli only...
-
mysqli_get_client_stats() -
mysqli_get_connection_stats() - mysqli_get_cache_stats()
Those three functions are ext/mysqlnd related, they are #ifdef 'ed in
the source code of ext/mysqli and not defined if ext/mysqli has been
compiled against libmysql.
There is a mismatch in the naming and the place here, those 3
functions should be part of ext/mysqlnd API, and be named
mysqlnd_****().
What if I choose to only compile pdo_mysql (against mysqlnd) and not
mysqli ?? I then would be able to use mysqlnd, but I would have access
to its statistics, as its functions are part of ext/mysqli... Strange
as well as embarrassing isn't it ?
I then suggest to expose ext/mysqlnd API through itself
(http://lxr.php.net/xref/PHP_5_3/ext/mysqlnd/php_mysqlnd.c#33) in
php_mysqlnd.c or create a new php_mysqlnd_fe.c
For the actual functions, please refer to
http://lxr.php.net/xref/PHP_5_3/ext/mysqli/mysqli_nonapi.c#392
Second, I would suggest to add a function that would reset the global
stat counter. The only way to do it actually is by passing in MINIT(),
so by restarting PHP ; it may be useful, and not very hard to develop,
to create a mysqlnd_stats_reset($someOptionsIfNeeded) function.
Any ideas, comments ?
Cheers,
Julien
mysqli_get_client_stats()mysqli_get_connection_stats()- mysqli_get_cache_stats()
Those three functions are ext/mysqlnd related, they are #ifdef 'ed in
the source code of ext/mysqli and not defined if ext/mysqli has been
compiled against libmysql.
With libmysql we don't have the statistics, therefore they are useless.
There is a mismatch in the naming and the place here, those 3
functions should be part of ext/mysqlnd API, and be named
mysqlnd_****().
Until 5.4 we couldn't do "mysqlnd_get_connection_stats" as there was no
way to get from an arbitrary zval (PDO or mysqli object, mysql resource)
to the corresponding MYSQLND*.
The other reason is that one idea for mysqlnd was that it doesn't expose
anything to the userland while ext/mysql is legacy and get's no
additions and PDO would allow user-defined functions,while that's not
really nice.
What if I choose to only compile pdo_mysql (against mysqlnd) and not
mysqli ?? I then would be able to use mysqlnd, but I would have access
to its statistics, as its functions are part of ext/mysqli... Strange
as well as embarrassing isn't it ?
You simply shouldn't do that ;-)
Second, I would suggest to add a function that would reset the global
stat counter. The only way to do it actually is by passing in MINIT(),
so by restarting PHP ; it may be useful, and not very hard to develop,
to create a mysqlnd_stats_reset($someOptionsIfNeeded) function.Any ideas, comments ?
Feel free to open a ticket in the bug tracker and assign it to us (mysql
user).
johannes
Johannes Schlüter, MySQL Engineering Connectors and Client Connectivity
ORACLE Deutschland B.V. & Co. KG, Riesstr. 25, D-80992 München
2012/4/24 Johannes Schlüter johannes.schlueter@oracle.com:
mysqli_get_client_stats()mysqli_get_connection_stats()- mysqli_get_cache_stats()
Those three functions are ext/mysqlnd related, they are #ifdef 'ed in
the source code of ext/mysqli and not defined if ext/mysqli has been
compiled against libmysql.With libmysql we don't have the statistics, therefore they are useless.
Right, NP
There is a mismatch in the naming and the place here, those 3
functions should be part of ext/mysqlnd API, and be named
mysqlnd_****().Until 5.4 we couldn't do "mysqlnd_get_connection_stats" as there was no
way to get from an arbitrary zval (PDO or mysqli object, mysql resource)
to the corresponding MYSQLND*.
Aha, I like when an internals guy teach me internals stuff :)
So, OK for 5.3 , what about supporting that for >=5.4 ?
The other reason is that one idea for mysqlnd was that it doesn't expose
anything to the userland while ext/mysql is legacy and get's no
additions and PDO would allow user-defined functions,while that's not
really nice.
That was my first question : Is it better to provide mysqlnd API
through all 3 MySQL extensions, or through a common mysqlnd_() API
?
I understand your thoughts, but I disagree as I think it would be much
more clean to expose it via mysqlnd_() API than through each MySQL
ext (and for PDO that would be even more dirty). That would as well
add more and more #ifdef MYSQLND inside their source...
I was thinking the same way libxml2 API is provided inside ext/libxml
instead of through each PHP XML extension API.
What if I choose to only compile pdo_mysql (against mysqlnd) and not
mysqli ?? I then would be able to use mysqlnd, but I would have access
to its statistics, as its functions are part of ext/mysqli... Strange
as well as embarrassing isn't it ?You simply shouldn't do that ;-)
;-) OK, but that can be done easily. More and more people use
pdo_mysql and could be able to not compile other MySQL extensions (I
got some machines where only pdo_mysql is compiled in)
Second, I would suggest to add a function that would reset the global
stat counter. The only way to do it actually is by passing in MINIT(),
so by restarting PHP ; it may be useful, and not very hard to develop,
to create a mysqlnd_stats_reset($someOptionsIfNeeded) function.Any ideas, comments ?
Feel free to open a ticket in the bug tracker and assign it to us (mysql
user).
More, I'm gonna work on a patch to feed the bug report with ;-)
Stats are not the hardest part of ext/mysqlnd :)
Julien.P
Am 24.04.2012 14:27, schrieb jpauli:
I understand your thoughts, but I disagree as I think it would be much
more clean to expose it via mysqlnd_***() API than through each MySQL
ext (and for PDO that would be even more dirty). That would as well
add more and more #ifdef MYSQLND inside their source...
I was thinking the same way libxml2 API is provided inside ext/libxml
instead of through each PHP XML extension API.
A fourth MySQL API is not my goal. There's enough confusion with three
of them already.
Ulf
Am 24.04.2012 14:27, schrieb jpauli:
I understand your thoughts, but I disagree as I think it would be much
more clean to expose it via mysqlnd_***() API than through each MySQL
ext (and for PDO that would be even more dirty). That would as well
add more and more #ifdef MYSQLND inside their source...
I was thinking the same way libxml2 API is provided inside ext/libxml
instead of through each PHP XML extension API.A fourth MySQL API is not my goal. There's enough confusion with three of
them already.
I agree with that, but I still think having mysqli_***() function that
is only related to mysqlnd stuff is a bad idea.
Julien
Hi,
Am 24.04.2012 14:27, schrieb jpauli:
I understand your thoughts, but I disagree as I think it would be much
more clean to expose it via mysqlnd_***() API than through each MySQL
ext (and for PDO that would be even more dirty). That would as well
add more and more #ifdef MYSQLND inside their source...
I was thinking the same way libxml2 API is provided inside ext/libxml
instead of through each PHP XML extension API.A fourth MySQL API is not my goal. There's enough confusion with three of
them already.I agree with that, but I still think having mysqli_***() function that
is only related to mysqlnd stuff is a bad idea.
you probably hasn't seen mysqli_stmt_get_result() and result::fetch_all() :)
Julien
Andrey
Aha, I like when an internals guy teach me internals stuff :)
So, OK for 5.3 , what about supporting that for >=5.4 ?
Maybe. ;-)
The other reason is that one idea for mysqlnd was that it doesn't expose
anything to the userland while ext/mysql is legacy and get's no
additions and PDO would allow user-defined functions,while that's not
really nice.That was my first question : Is it better to provide mysqlnd API
through all 3 MySQL extensions, or through a common mysqlnd_() API
?
I understand your thoughts, but I disagree as I think it would be much
more clean to expose it via mysqlnd_() API than through each MySQL
ext (and for PDO that would be even more dirty). That would as well
add more and more #ifdef MYSQLND inside their source...
I was thinking the same way libxml2 API is provided inside ext/libxml
instead of through each PHP XML extension API.
Well, as said, we couldn't before 5.4. I gave the "historical" reason
for the current state.
What if I choose to only compile pdo_mysql (against mysqlnd) and not
mysqli ?? I then would be able to use mysqlnd, but I would have access
to its statistics, as its functions are part of ext/mysqli... Strange
as well as embarrassing isn't it ?You simply shouldn't do that ;-)
;-) OK, but that can be done easily. More and more people use
pdo_mysql and could be able to not compile other MySQL extensions (I
got some machines where only pdo_mysql is compiled in)
All distros I recently checked put all three mysql extensions in the
same package. People who build PHP themselves should be able to fix this
easily. So this does not seem to be an issue. (while that's irrelevant
for the mysqli vs. myslqnd question)
johannes
2012/4/24 Johannes Schlüter johannes.schlueter@oracle.com:
Aha, I like when an internals guy teach me internals stuff :)
So, OK for 5.3 , what about supporting that for >=5.4 ?Maybe. ;-)
I can start working on ideas/patches
The other reason is that one idea for mysqlnd was that it doesn't expose
anything to the userland while ext/mysql is legacy and get's no
additions and PDO would allow user-defined functions,while that's not
really nice.That was my first question : Is it better to provide mysqlnd API
through all 3 MySQL extensions, or through a common mysqlnd_() API
?
I understand your thoughts, but I disagree as I think it would be much
more clean to expose it via mysqlnd_() API than through each MySQL
ext (and for PDO that would be even more dirty). That would as well
add more and more #ifdef MYSQLND inside their source...
I was thinking the same way libxml2 API is provided inside ext/libxml
instead of through each PHP XML extension API.Well, as said, we couldn't before 5.4. I gave the "historical" reason
for the current state.
Got it, got it.
What if I choose to only compile pdo_mysql (against mysqlnd) and not
mysqli ?? I then would be able to use mysqlnd, but I would have access
to its statistics, as its functions are part of ext/mysqli... Strange
as well as embarrassing isn't it ?You simply shouldn't do that ;-)
;-) OK, but that can be done easily. More and more people use
pdo_mysql and could be able to not compile other MySQL extensions (I
got some machines where only pdo_mysql is compiled in)All distros I recently checked put all three mysql extensions in the
same package. People who build PHP themselves should be able to fix this
easily. So this does not seem to be an issue. (while that's irrelevant
for the mysqli vs. myslqnd question)
Makes sense.
Julien