Hi,
when building PHP using
(I) ./configure --with-mysql --with-mysqli --with-pdo-mysql
you currently get a build using the system default libmysql, usually
in /us or
such. Alternatively PHP can be built using
(II) ./configure --with-mysqli=mysqlnd [...]
to build the MySQL extensions using the mysqlnd library.
I would like to change mysqlnd's config9.m4 file to build PHP using
mysqlnd when being called in form (I). Users would still be able to
enforce libmysql by passing a path, like /usr.
There are two main reasons I see for this:
a) Different libmysql versions have slightly different behavior,
which shows in our tests. We can't have both, a good test coverage
and cover all these differences. By using mysqlnd we have a clear
behavior every PHP developer can rely on.
b) We provide different extensions (pecl/mysqlnd_*) which
improve/extend mysqlnd functionality. By having mysqlnd as default
these are better usable by users.
Opinions?
johannes
Johannes Schlüter, Oracle
MySQL Engineering - MySQL Connectors and Client Connectivity
please do it
we are using mysqlnd on some hundret domains with all sort of php-software
since PHP 5.3.3 (the first 5.3 version we used) and thinking back how
hard it was to get the fedora-srpm chnaged to build with mysqlnd
my opinion is drop the libmysql-support completly
you named the main-reason for that: auto-tests
supporting both without a real good reason will have permanently
side-effects covered in bugreports and instead maintain two code-paths
from the view of quality it would be better to optimize mysqlnd
if there is something missing what i do not know now
Am 02.09.2011 14:27, schrieb Johannes Schlüter:
Hi,
when building PHP using
(I) ./configure --with-mysql --with-mysqli --with-pdo-mysql
you currently get a build using the system default libmysql, usually
in /us or
such. Alternatively PHP can be built using
(II) ./configure --with-mysqli=mysqlnd [...]
to build the MySQL extensions using the mysqlnd library.I would like to change mysqlnd's config9.m4 file to build PHP using
mysqlnd when being called in form (I). Users would still be able to
enforce libmysql by passing a path, like /usr.There are two main reasons I see for this:
a) Different libmysql versions have slightly different behavior,
which shows in our tests. We can't have both, a good test coverage
and cover all these differences. By using mysqlnd we have a clear
behavior every PHP developer can rely on.
b) We provide different extensions (pecl/mysqlnd_*) which
improve/extend mysqlnd functionality. By having mysqlnd as default
these are better usable by users.Opinions?
johannes
Am 02.09.2011 14:27, schrieb Johannes Schlüter:
I would like to change mysqlnd's config9.m4 file to build PHP using
mysqlnd when being called in form (I). Users would still be able to
enforce libmysql by passing a path, like /usr.
PLEASE do it :-)
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Hi,
when building PHP using
(I) ./configure --with-mysql --with-mysqli --with-pdo-mysql
you currently get a build using the system default libmysql, usually
in /us or
such. Alternatively PHP can be built using
(II) ./configure --with-mysqli=mysqlnd [...]
to build the MySQL extensions using the mysqlnd library.I would like to change mysqlnd's config9.m4 file to build PHP using
mysqlnd when being called in form (I). Users would still be able to
enforce libmysql by passing a path, like /usr.There are two main reasons I see for this:
a) Different libmysql versions have slightly different behavior,
which shows in our tests. We can't have both, a good test coverage
and cover all these differences. By using mysqlnd we have a clear
behavior every PHP developer can rely on.
b) We provide different extensions (pecl/mysqlnd_*) which
improve/extend mysqlnd functionality. By having mysqlnd as default
these are better usable by users.Opinions?
I was actually going to suggest doing this in 5.4 and trunk but didn't
get around to writing the email yet.
-Rasmus
Hi,
when building PHP using
(I) ./configure --with-mysql --with-mysqli --with-pdo-mysql
you currently get a build using the system default libmysql, usually
in /us or
such. Alternatively PHP can be built using
(II) ./configure --with-mysqli=mysqlnd [...]
to build the MySQL extensions using the mysqlnd library.I would like to change mysqlnd's config9.m4 file to build PHP using
mysqlnd when being called in form (I). Users would still be able to
enforce libmysql by passing a path, like /usr.There are two main reasons I see for this:
a) Different libmysql versions have slightly different behavior,
which shows in our tests. We can't have both, a good test coverage
and cover all these differences. By using mysqlnd we have a clear
behavior every PHP developer can rely on.
b) We provide different extensions (pecl/mysqlnd_*) which
improve/extend mysqlnd functionality. By having mysqlnd as default
these are better usable by users.Opinions?
I was actually going to suggest doing this in 5.4 and trunk but didn't
get around to writing the email yet.-Rasmus
I'm +1 for this. I think the decision & implementation needs to be done
before Beta or deferred to trunk.
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Hi!
I'm +1 for this. I think the decision& implementation needs to be done
before Beta or deferred to trunk.
Frankly, I'd be more comfortable with trunk. We have enough trouble with
unit tests etc. before the beta, and introducing profound change in
default without enough time for discussion and gathering feedback from
packagers, etc. doesn't look a smart thing to do.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I'm +1 for this. I think the decision& implementation needs to be done
before Beta or deferred to trunk.Frankly, I'd be more comfortable with trunk. We have enough trouble with unit tests etc. before the beta, and introducing profound change in default without enough time for discussion and gathering feedback from packagers, etc. doesn't look a smart thing
to do.
Let's see what other comments come in.
Doing it in 5.4 will make it easier to stabilize the tests and allow
trunk & 5.4 build & tests to be in sync. The user benefits include
more predictable behavior on edge cases, and presumably better
features & quality that core developers could fill their time working
on.
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Am 02.09.2011 21:24, schrieb Stas Malyshev:
Hi!
I'm +1 for this. I think the decision& implementation needs to be done
before Beta or deferred to trunk.Frankly, I'd be more comfortable with trunk. We have enough trouble with
unit tests etc. before the beta, and introducing profound change in
default without enough time for discussion and gathering feedback from
packagers, etc. doesn't look a smart thing to do.
Hmm, I do not understand the unit test argument. Non-portable tests
exist regardless of what the config.m4 default is.
We are talking about making mysqlnd as a compile default, if not
explicitly choosing libmysql to compile against. This is no attempt to
remove libmysql support. I somewhat assume most packagers do explicitly
set libmysql path already and do not rely on any magic, because they
don't use MySQL's default source layout. However, argument taken, let's
do some checks who (Debian, Ubuntu, OpenSuse, RH, ...) does not set
libmysql path during compile.
mysqlnd was introduced with PHP 5.3. IMHO, it has matured quite well.
Mysqlnd reduces the PHP projects dependency on anybody controlling the
library. This has been a major pain in the past. Think of builds made
against outdated versions of libmysql, think of waiting for new libmysql
releases, think of compilers not supported by libmysql, think of license
discussion, think of accepting code contributions and so forth.
From a user perspective mysqlnd removes the need to install libmyql
prior to building and a has a couple of neat features not available with
libmysql, for example, the plugins.
Ulf
+1 and agree that it should be implemented before the beta.
Am 02.09.2011 21:24, schrieb Stas Malyshev:
Hi!
I'm +1 for this. I think the decision& implementation needs to be done
before Beta or deferred to trunk.Frankly, I'd be more comfortable with trunk. We have enough trouble with
unit tests etc. before the beta, and introducing profound change in
default without enough time for discussion and gathering feedback from
packagers, etc. doesn't look a smart thing to do.Hmm, I do not understand the unit test argument. Non-portable tests exist
regardless of what the config.m4 default is.We are talking about making mysqlnd as a compile default, if not explicitly
choosing libmysql to compile against. This is no attempt to remove libmysql
support. I somewhat assume most packagers do explicitly set libmysql path
already and do not rely on any magic, because they don't use MySQL's default
source layout. However, argument taken, let's do some checks who (Debian,
Ubuntu, OpenSuse, RH, ...) does not set libmysql path during compile.mysqlnd was introduced with PHP 5.3. IMHO, it has matured quite well.
Mysqlnd reduces the PHP projects dependency on anybody controlling the
library. This has been a major pain in the past. Think of builds made
against outdated versions of libmysql, think of waiting for new libmysql
releases, think of compilers not supported by libmysql, think of license
discussion, think of accepting code contributions and so forth.From a user perspective mysqlnd removes the need to install libmyql prior
to building and a has a couple of neat features not available with libmysql,
for example, the plugins.Ulf
--
--
"My command is this: Love each other as I
have loved you." John 15:12
Hi!
I'm +1 for this. I think the decision& implementation needs to be done
before Beta or deferred to trunk.Frankly, I'd be more comfortable with trunk. We have enough trouble with
unit tests etc. before the beta, and introducing profound change in
default without enough time for discussion and gathering feedback from
packagers, etc. doesn't look a smart thing to do.
Actually the testing point was the trigger for me to write this mail.
I/We should have done it earlier but for me it's too normal to build
using mysqlnd.
Looking at the tests we have: Most tests are written with mysqlnd in
focus. mysqlnd is what we (Oracle/MySQL) test the most in PHP
perspective for quite some time already. By making mysqlnd the default
we remove one moving piece out of the test equation which simplifies
tests[1]. (we still have multiple server versions to keep in mind ...)
Looking at the last test results Rasmus' sent (using my own would be a
lame cheat ;-) ) he had 6 mysqlnd test failures of which we fixed most
(we also fixed others) whereas libmysql builds have more (depending on
versions). Yes we could spend a few more days and do massive builds of
different combinations (and make the tests more complex to cover
multiple cases) or focus on having a good and stable default which
behaves the same on all platforms.
Looking at distributions: On Windows (which probably is the single most
used build of PHP at all) we're using mysqlnd by default since 5.3.0.
This had some pain in the beginning but went, aside from the recent
OpenSSL issue, quite soomthly. Some other packagers we could meanwhile
convince to use mysqlnd others told me things which boil down to "if PHP
makes it default we use it". So I see little risk there.
johannes
[1] Yes, we will still allow building with libmysql and we will fix bugs
reported there and we will verify it works but focus on mysqlnd, as
we're actually handling it already
--
Johannes Schlüter, Oracle
MySQL Engineering - connectors and Client Connectivity
Hi!
Looking at the tests we have: Most tests are written with mysqlnd in
focus. mysqlnd is what we (Oracle/MySQL) test the most in PHP
perspective for quite some time already. By making mysqlnd the default
we remove one moving piece out of the test equation which simplifies
tests[1]. (we still have multiple server versions to keep in mind ...)
Are you implying you would no longer fix failures on libmysql? If so, we
should announce libmysql is unsupported and I definitely am against
doing anything like this in 5.4. If you are not meaning this, then
absolutely nothing changes with regard to unit tests - they still must
pass on both modes.
different combinations (and make the tests more complex to cover
multiple cases) or focus on having a good and stable default which
behaves the same on all platforms.
We should focus on having unit tests passing, otherwise there's no point
in having them. If we do not drop libmysql support, we should have
exactly the same results in libmysql as we have in mysqlnd. Otherwise it
is called "unsupported configuration". If the plan is to keep pretense
of supporting libmysql while actually neglecting to do fixes and fix
tests for it in hope that people would eventually switch - this is not
the right way to do it.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
2011/9/2 Stas Malyshev smalyshev@sugarcrm.com:
Hi!
Looking at the tests we have: Most tests are written with mysqlnd in
focus. mysqlnd is what we (Oracle/MySQL) test the most in PHP
perspective for quite some time already. By making mysqlnd the default
we remove one moving piece out of the test equation which simplifies
tests[1]. (we still have multiple server versions to keep in mind ...)Are you implying you would no longer fix failures on libmysql? If so, we
should announce libmysql is unsupported and I definitely am against doing
anything like this in 5.4. If you are not meaning this, then absolutely
nothing changes with regard to unit tests - they still must pass on both
modes.
I think you missed the referenced [1]:
[1] Yes, we will still allow building with libmysql and we will fix bugs
reported there and we will verify it works but focus on mysqlnd, as
we're actually handling it already
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
I think you missed the referenced [1]:
[1] Yes, we will still allow building with libmysql and we will fix bugs
reported there and we will verify it works but focus on mysqlnd, as
we're actually handling it already
I did not miss it - I do not see what it means. Either we support both -
and then for the matter of development and testing nothing changes - or
something changes, namely "we remove one moving piece out of the test
equation", the moving piece being libmysql - and "remove" means
"remove". I just don't see how you can have both of these things at the
same time.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I think you missed the referenced [1]:
[1] Yes, we will still allow building with libmysql and we will fix bugs
reported there and we will verify it works but focus on mysqlnd, as
we're actually handling it alreadyI did not miss it - I do not see what it means. Either we support both - and
then for the matter of development and testing nothing changes - or
something changes, namely "we remove one moving piece out of the test
equation", the moving piece being libmysql - and "remove" means "remove". I
just don't see how you can have both of these things at the same time.
I think that Johannes means that mysqld would be the preferred or
baseline for the mysql tests.
maybe supporting IE6 would be a good metaphor: you could say that you
support every browser equally, or you could say that you write your
stuff for the modern browsers and tests it against IE6 and fix where
necessary.
Johannes, is this what you had in mind?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
I think you missed the referenced [1]:
[1] Yes, we will still allow building with libmysql and we will fix bugs
reported there and we will verify it works but focus on mysqlnd, as
we're actually handling it alreadyI did not miss it - I do not see what it means. Either we support both - and
then for the matter of development and testing nothing changes - or
something changes, namely "we remove one moving piece out of the test
equation", the moving piece being libmysql - and "remove" means "remove". I
just don't see how you can have both of these things at the same time.I think that Johannes means that mysqld would be the preferred or
baseline for the mysql tests.
maybe supporting IE6 would be a good metaphor: you could say that you
support every browser equally, or you could say that you write your
stuff for the modern browsers and tests it against IE6 and fix where
necessary.
Johannes, is this what you had in mind?
Thanks, I like your analogy and don't have a better one.
johannes
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Am 02.09.2011 22:57, schrieb Johannes Schlüter:
Hi!
I think you missed the referenced [1]:
[1] Yes, we will still allow building with libmysql and we will fix bugs
reported there and we will verify it works but focus on mysqlnd, as
we're actually handling it alreadyI did not miss it - I do not see what it means. Either we support both - and
then for the matter of development and testing nothing changes - or
something changes, namely "we remove one moving piece out of the test
equation", the moving piece being libmysql - and "remove" means "remove". I
just don't see how you can have both of these things at the same time.I think that Johannes means that mysqld would be the preferred or
baseline for the mysql tests.
maybe supporting IE6 would be a good metaphor: you could say that you
support every browser equally, or you could say that you write your
stuff for the modern browsers and tests it against IE6 and fix where
necessary.
Johannes, is this what you had in mind?Thanks, I like your analogy and don't have a better one.
Let's see if I get it right.
Johannes and I say:
- libmysql support is there and it will stay there
- libmysql shall continue to be supported
- tests shall be written in a portable way, whenever possible
We furthermore said, let me put it straigt:
- we failed to catch some libmysql/MySQL/test version combination
portability issues - shit happens, sorry for that - testing any extension that has external dependencies is a pain
I think, such a statement is quite a big step towards your test
concerns, Stas. Ultimately, I still don't get what you (Stas) are after
with the test discussion. Have I missed any of your worries?
Ulf
Hi!
I think, such a statement is quite a big step towards your test
concerns, Stas. Ultimately, I still don't get what you (Stas) are after
with the test discussion. Have I missed any of your worries?
My concerns is first and foremost to have unit tests passing and
compatibility API issues sorted out - such as same functions producing
different semantics on libmysql and mysqlnd. This is my primary concern,
especially if we want to have beta anytime soon :)
That said, talk about "removing one moving piece out of the test
equation" and comparing libmysql support to universally unsupported and
officially considered dead IE6 makes me worried, when it comes from
mysql extension maintainers. Your clarification about it in this letter
makes clear my concerns are unfounded, which is good. Let's now get back
to the first part - the failing tests.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Am 02.09.2011 23:30, schrieb Stas Malyshev:
Hi!
I think, such a statement is quite a big step towards your test
concerns, Stas. Ultimately, I still don't get what you (Stas) are after
with the test discussion. Have I missed any of your worries?My concerns is first and foremost to have unit tests passing and
compatibility API issues sorted out - such as same functions producing
different semantics on libmysql and mysqlnd. This is my primary concern,
especially if we want to have beta anytime soon :)
Stas,
if you are really concerned about tests, aren't you a bit late, are all
the 5.3 releases to be considered instable. I mean, they use the same
tests. Andrey may know better, but I even assume mysqlnd to be very,
very similar in 5.3 and 5.4. How strong is your argument, how many
critical differences are you aware of that prevent a config.m4 change?
If there are criticial differences of much practical relevance, how
could we miss them, why are we not seeing more bug reports?
With all given respect, I think you are going a bit far here. You seem
to be extrapolating from "test x does not work in configuration y" to "z
is instable/incompatible with y".
You have one argument against the config.m4 change that I get - the
packaging/distribution one. But the test does not pass with X/Y/Z_old
seems a bit weak to me.
I hope, nobody is angry if I call it a day.
Enjoy the weekend,
Ulf
Hi!
if you are really concerned about tests, aren't you a bit late, are all
the 5.3 releases to be considered instable. I mean, they use the same
The fact that 5.3 had so many failing tests is nothing good, but we
can't fix the past. We can try to make it not happen in the future -
namely, in 5.4.
tests. Andrey may know better, but I even assume mysqlnd to be very,
very similar in 5.3 and 5.4. How strong is your argument, how many
critical differences are you aware of that prevent a config.m4 change?
None of these issues prevent the default change, the default change is a
completely separate issue. I just think introducing another issue to
deal with - and literally days before the release, without any serious
discussion - is wrong. We were burned so many times on this, and there's
absolutely no reason to rush with it.
This is absolutely different and unrelated issue to the issue of unit
tests, except for the fact that I do this there's a reason to rush with
that and I want our energies rather be spent on that.
With all given respect, I think you are going a bit far here. You seem
to be extrapolating from "test x does not work in configuration y" to "z
is instable/incompatible with y".
Oh no, I didn't make any claims about mysqlnd being unstable, if I said
something that can be understood that I have misspoken and that's not
what I meant to say. I'm just trying to avoid late-minute changes
without enough consideration.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
maybe supporting IE6 would be a good metaphor: you could say that you
support every browser equally, or you could say that you write your
stuff for the modern browsers and tests it against IE6 and fix where
necessary.
Johannes, is this what you had in mind?Thanks, I like your analogy and don't have a better one.
That is exactly the problem - nobody says "we support every browser
equally" and most sites/applications explicitly say "we do not support
IE6" and every bug on IE6 is rejected unless it happens in some other
place. If you plan to give libmysql the same treatment it means removing
support for it, plain and simple. If you mean something else, please
explain.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Am 02.09.2011 23:20, schrieb Stas Malyshev:
Hi!
maybe supporting IE6 would be a good metaphor: you could say that you
support every browser equally, or you could say that you write your
stuff for the modern browsers and tests it against IE6 and fix where
necessary.
Johannes, is this what you had in mind?Thanks, I like your analogy and don't have a better one.
That is exactly the problem - nobody says "we support every browser
equally" and most sites/applications explicitly say "we do not support
IE6" and every bug on IE6 is rejected unless it happens in some other
place. If you plan to give libmysql the same treatment it means removing
support for it, plain and simple. If you mean something else, please
explain.
Stas,
what is not clear from my last mail?
Ulf
Hi Stas,
Hi!
I think you missed the referenced [1]:
[1] Yes, we will still allow building with libmysql and we will fix bugs
reported there and we will verify it works but focus on mysqlnd, as
we're actually handling it alreadyI did not miss it - I do not see what it means. Either we support both -
and then for the matter of development and testing nothing changes - or
something changes, namely "we remove one moving piece out of the test
equation", the moving piece being libmysql - and "remove" means
"remove". I just don't see how you can have both of these things at the
same time.
the problem is that libmysql breaks, maybe more often than mysqlnd does.
We rarely find bugs in mysqli, there are two codepaths in mysqli. If
there is a bug in libmysql, what do you want:
- SKIP, because either libmysql or the server is buggy, but many tests
do skip and does anyone read the skip messages? But your environment is
buggy, which means that your application will possibly FAIL. Instead of
finding, that your environment is broken you will skip this
information. Good luck finding later that you hit a bug, which other
knew about but you did not get that info, because of SKIP - FAIL, and one does look at the failures. You might then notice that
your libmysql and/or server is buggy. You might do something, check for
existing bug, see if it is fixed and possible update or at least you can
try to assess what the impact on you it will have.
Best,
Andrey
Hi!
the problem is that libmysql breaks, maybe more often than mysqlnd does.
We rarely find bugs in mysqli, there are two codepaths in mysqli. If
there is a bug in libmysql, what do you want:
If we're dealing with libmysql bug, then I guess the expected thing
would be to report it upstream, and make the comment in the test with
bug ID. But in the cases I mentioned it does not look like libmysql bug
as everything works just according to Mysql documentation, however the
tests expect it to work differently.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Am 05.09.2011 11:08, schrieb Stas Malyshev:
Hi!
the problem is that libmysql breaks, maybe more often than mysqlnd does.
We rarely find bugs in mysqli, there are two codepaths in mysqli. If
there is a bug in libmysql, what do you want:If we're dealing with libmysql bug, then I guess the expected thing would be to report it upstream, and make the
comment in the test with bug ID. But in the cases I mentioned it does not look like libmysql bug as everything
works just according to Mysql documentation, however the tests expect it to work differently
the point is not a single test NOW
the point is FUTURE and PHP 5.4
we are speaking not about a current libmysql bug, we are speaking about
bugs in the past and possible bugs in the future and the difference is
that using mysqlnd is removing the unknown variable "libmysql version"
Am 05.09.2011 11:08, schrieb Stas Malyshev:
Hi!
the problem is that libmysql breaks, maybe more often than mysqlnd does.
We rarely find bugs in mysqli, there are two codepaths in mysqli. If
there is a bug in libmysql, what do you want:If we're dealing with libmysql bug, then I guess the expected thing
would be to report it upstream, and make the comment in the test with
bug ID. But in the cases I mentioned it does not look like libmysql bug
as everything works just according to Mysql documentation, however the
tests expect it to work differently.
Stas,
what are we going to do now after the discussion has calmed down a bit?
Any new PHP major release is about setting new directions. I, Andrey and
Johannes, the guys maintaining ext/mysql recommend going mysqlnd after
an "incubation" of some four years (5.3x series + dev time).
You, in your role as 5.4 RM, raised some concerns about changing the
default to mysqlnd. Your primary concern is rolling out something that
breaks PHP.
As an example, you have listed some mysqli test failures. After the
weekend, I'm a lazy bastard refusing to work during weekends, test
failures have been commented on:
- connect_oo_* - libmysql only, no BC [1]
- explain_meta - libmysql can crash PHP, mysqlnd works [2]
- stmt_num_rows - differences in undefined behaviour [3]
- insert_id - as a bug, it would be bogussed, undefined [4]
Your four examples stand up against, for example, Pierre "Windows" Joye.
The php.net windows binaries are using mysqlnd as of PHP 5.3. Windows is
probaly the biggest individual distribution. Pierre, who is no MySQL fan
boy, reports no BC issues. This is based on multiple years of php.net
Windows users feedback and his continous integration testing using
"drupal 6&7, wp, oscommerce, mediawiki, sugarcrm, etc." [5]. At least on
Windows, users do expect to see mysqlnd meanwhile.
Harald Reindl did the switch from libmysql to mysqlnd on "hundret
domains" with "no single problem" [6]. OpenSuSE did the same.
As a manager, you often have to make a decision without knowing all
details, without checking everything yourself. You have named and set
the #1 risk (BC) and heard people's opinion: mysqlnd is not flawless,
but well worth a try.
You also raised the question how or if a change will impact packagers.
Tomas Kuliavas gave some great input on this [7]:
SuSE:
--with-mysql=shared,mysqlnd
Debian, Mandriva and Fedora:
--with-mysql=shared,/usr
--with-mysqli=shared,/usr/bin/mysql_config'
Looks like packages explicitly set config options. Thus, no break
provoked if changing defaults. There's a bit of a buzz on shared builds,
Johannes is working on that one - https://bugs.php.net/bug.php?id=55609 .
IMHO all of the relevant concerns have been adressed. No high risks have
been found. There is nothing in the way that cannot be tackled down as
one moves forward.
I see no reason for ignoring the vote of the maintainers. I fail to
understand why PHP @ *nix should not catch up to Windows.
Ulf
[1] http://news.php.net/php.internals/55226
[2] http://news.php.net/php.internals/55221
[3] http://news.php.net/php.internals/55210
[4] http://news.php.net/php.internals/55228
[5] http://news.php.net/php.internals/55177
[6] http://news.php.net/php.internals/55174
[7] http://news.php.net/php.internals/55142
Hi!
Any new PHP major release is about setting new directions. I, Andrey and
Johannes, the guys maintaining ext/mysql recommend going mysqlnd after
an "incubation" of some four years (5.3x series + dev time).
My concern was also that making mysqlnd the default would make libmysql
support considered secondary and unimportant. As I was assured it is not
the case and the differences between mysqlnd and libmysql flavors seem
to be rectified or in the process of being rectified, and I heard no
objections for this as a default, I'm OK with it now.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Am 06.09.2011 21:33, schrieb Stas Malyshev:
Hi!
Any new PHP major release is about setting new directions. I, Andrey and
Johannes, the guys maintaining ext/mysql recommend going mysqlnd after
an "incubation" of some four years (5.3x series + dev time).My concern was also that making mysqlnd the default would make libmysql
support considered secondary and unimportant. As I was assured it is not
the case and the differences between mysqlnd and libmysql flavors seem
to be rectified or in the process of being rectified, and I heard no
objections for this as a default, I'm OK with it now.
Jippie!
Removing libmysql support would be crazy. Not only from a PHP
perspective but also from a MySQL one. For PHP it is a must-have
fallback option. For MySQL the PHP stuff is a nice libmysql test drive.
Not a welcome job among the mysqlnd fan boys, as you noticed. But then,
sometimes we count mysqlnd vs. libmysql issues...
Ulf
2011.09.06 23:20 Ulf Wendel rašė:
Am 06.09.2011 21:33, schrieb Stas Malyshev:
Hi!
Any new PHP major release is about setting new directions. I, Andrey
and
Johannes, the guys maintaining ext/mysql recommend going mysqlnd
after
an "incubation" of some four years (5.3x series + dev time).My concern was also that making mysqlnd the default would make libmysql
support considered secondary and unimportant. As I was assured it is not
the case and the differences between mysqlnd and libmysql flavors seem
to be rectified or in the process of being rectified, and I heard no
objections for this as a default, I'm OK with it now.Jippie!
Removing libmysql support would be crazy. Not only from a PHP
perspective but also from a MySQL one. For PHP it is a must-have
fallback option. For MySQL the PHP stuff is a nice libmysql test drive.
Not a welcome job among the mysqlnd fan boys, as you noticed. But then,
sometimes we count mysqlnd vs. libmysql issues...
Bouncing bug reports (https://bugs.php.net/bug.php?id=55001) that are not
reproducible on setup with mysqlnd when user reports about issue with
libmysql is not the way bugs are solved. mysqlnd is not authoritative
source for mysql extension behavior. libmysql is. That bug report shows
semantics differences Stas was talking about and bug status shows the way
you are handling it. If libmysql semantics change between versions,
indicate that in bug report instead refusing to solve the problem with
'mysqlnd works fine'
--
Tomas
Hi,
2011.09.06 23:20 Ulf Wendel rašė:
Am 06.09.2011 21:33, schrieb Stas Malyshev:
Hi!
Any new PHP major release is about setting new directions. I, Andrey
and
Johannes, the guys maintaining ext/mysql recommend going mysqlnd
after
an "incubation" of some four years (5.3x series + dev time).My concern was also that making mysqlnd the default would make libmysql
support considered secondary and unimportant. As I was assured it is not
the case and the differences between mysqlnd and libmysql flavors seem
to be rectified or in the process of being rectified, and I heard no
objections for this as a default, I'm OK with it now.Jippie!
Removing libmysql support would be crazy. Not only from a PHP
perspective but also from a MySQL one. For PHP it is a must-have
fallback option. For MySQL the PHP stuff is a nice libmysql test drive.
Not a welcome job among the mysqlnd fan boys, as you noticed. But then,
sometimes we count mysqlnd vs. libmysql issues...Bouncing bug reports (https://bugs.php.net/bug.php?id=55001) that are not
reproducible on setup with mysqlnd when user reports about issue with
libmysql is not the way bugs are solved. mysqlnd is not authoritative
source for mysql extension behavior. libmysql is. That bug report shows
semantics differences Stas was talking about and bug status shows the way
you are handling it. If libmysql semantics change between versions,
indicate that in bug report instead refusing to solve the problem with
'mysqlnd works fine'
The specific case you are talking about is a bug in libmysql. Seems like
a very old one as it has been reproduced with a vast range of versions.
What Ulf tells you is that you might want to consider mysqlnd, as it had
exposed less bugs than libmysql did so far and crashes less in some
weirdo cases, than libmysql does. And we talk about libmysql, not the
extensions than wrap it.
The interface to libmysql won't die, we will support it but be sure that
mysqlnd will be better because it is and will be engineered towards the
needs of PHP and not like libmysql towards the needs of everyone but the
aliens.
I hope that even the hardcore supporters for mysqlX@libmysql will some
day realize that waiting for a libmysql fix in a mission critical
environment will cost them (in time and hence money) a lot more than
waiting for the proper mysqlnd fix (applying a patch from svn).
Best,
Andrey
2011/9/2 Stas Malyshev smalyshev@sugarcrm.com:
Hi!
Looking at the tests we have: Most tests are written with mysqlnd in
focus. mysqlnd is what we (Oracle/MySQL) test the most in PHP
perspective for quite some time already. By making mysqlnd the default
we remove one moving piece out of the test equation which simplifies
tests[1]. (we still have multiple server versions to keep in mind ...)Are you implying you would no longer fix failures on libmysql?
The problem is the exact opposite, the fact that mysqlnd is not
default makes the bugs hunting harder for this backend. Most bad bugs
(thread safe related for example) come from the windows where mysqlnd
is already the only and default option. So having more users now in
5.4-beta will only help to make it even more stable.
While limysql is still a good alternative (slightly faster in some
cases) and does not have some of the TS issues we meet with mysqlnd,
but both are certainly temporary states.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
I'm +1 for this. I think the decision& implementation needs to be done
before Beta or deferred to trunk.Frankly, I'd be more comfortable with trunk. We have enough trouble with
unit tests etc. before the beta, and introducing profound change in
default without enough time for discussion and gathering feedback from
packagers, etc. doesn't look a smart thing to do.
I would agree with this if the mysqlnd option had more test failures
than the current default. But right now it it the complete opposite.
Linking with mysqlnd has far fewer test failures than linking with
whatever libmysql happens to be installed on the system.
One of the goals before the beta is to get to 0 failed tests for a
common build. Unless you simply skip all the failing libmysql tests,
that's going to be hard to do unless we move the default to a more
robust library. That doesn't mean we shouldn't fix all the weird
libmysql test failures. Heck, 2 of the tests segfault PHP on my Ubuntu
box when I link against libmysql, so there are some serious problems there.
-Rasmus
Hi!
One of the goals before the beta is to get to 0 failed tests for a
common build. Unless you simply skip all the failing libmysql tests,
that's going to be hard to do unless we move the default to a more
robust library. That doesn't mean we shouldn't fix all the weird
How moving default changes anything?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
One of the goals before the beta is to get to 0 failed tests for a
common build. Unless you simply skip all the failing libmysql tests,
that's going to be hard to do unless we move the default to a more
robust library. That doesn't mean we shouldn't fix all the weirdHow moving default changes anything?
Well, we are not trying to get to 0 failed tests in all permutations of
all extensions on all platforms. We are trying to get to 0 failed tests
on a common-case build using defaults and common extensions. Given that,
changing a default has an impact on the 0-failed-tests goal.
-Rasmus
Hi!
Well, we are not trying to get to 0 failed tests in all permutations of
all extensions on all platforms. We are trying to get to 0 failed tests
on a common-case build using defaults and common extensions. Given that,
changing a default has an impact on the 0-failed-tests goal.
Nobody talks about "all permutations of all platforms", let's not be
absurd here. However, there's a distance between "all permutations of
all platforms" and "we'll be ignoring failures on libmysql". libmysql
is the common case build and the one most people would be running in
production, at least as far as I see around.
So are you saying we'll be ignoring failures on libmysql? If we're not,
changing the default doesn't have any impact on the 0-failed-tests goal.
If you're saying we will, I think it would be a huge mistake - we'd do
better skipping out problematic tests (which I also think is wrong,
especially if these tests discover API incompatibility which shouldn't
even exist between mysqlnd and libmysql) than just ignore the failures.
We all see where ignoring failed tests got us. Let's not set ourselves
for this again from the start.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Am 03.09.2011 03:08, schrieb Stas Malyshev:
Hi!
Well, we are not trying to get to 0 failed tests in all permutations of
all extensions on all platforms. We are trying to get to 0 failed tests
on a common-case build using defaults and common extensions. Given that,
changing a default has an impact on the 0-failed-tests goal.libmysql is the common case build and the one most people would be running in production
but WHY is this so and are we not talking about the future here?
because it is the default
because there are two code-paths supported
why not remove libmysql-support completly?
is mysqlmd missing anything?
if yes - it should be improved
the benefits are:
- ONE codebase of mysql-drivers
- ONE codebase autotests rely on
- no install-dependencies for mysql-client
- faster
- less memory usage
Hi Folks:
we'd do better skipping out problematic tests (which
I also think is wrong, especially if these tests discover API
incompatibility which shouldn't even exist between mysqlnd and
libmysql) than just ignore the failures.
I don't know why there are differences in the output between mysqlnd and
libmysql. It would be nice if there weren't. But if that can't be,
two options come to mind for testing each feature:
a) have the feature tested against the lowest common denominator (by
either using expressions in an EXPECTF section or only producing output
that is consistent).
b) have two tests for the feature (one for mysqlnd and another for
libmysql, with SKIP's being emitted when running on the opposite
platform).
But what do I know...
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
Hi!
Well, we are not trying to get to 0 failed tests in all permutations of
all extensions on all platforms. We are trying to get to 0 failed tests
on a common-case build using defaults and common extensions. Given that,
changing a default has an impact on the 0-failed-tests goal.Nobody talks about "all permutations of all platforms", let's not be
absurd here. However, there's a distance between "all permutations of
all platforms" and "we'll be ignoring failures on libmysql". libmysql
is the common case build and the one most people would be running in
production, at least as far as I see around.
Ah yes, but is that because they have actively chosen to use libmysql or
is it because our default is libmysql. It is buggier and less robust
than mysqlnd at this point, at least in my experience, so who are we
helping by leaving libmysql as the default?
Forget the failed tests. A new PHP release is about improving the
ecosystem. If the folks that maintain libmysql and mysqlnd suggest that
mysqlnd is more robust and it is the path forward, why would we resist
this? Do we not trust Oracle/MySQL enough to listen to their input?
-Rasmus
Am 03.09.2011 03:51, schrieb Rasmus Lerdorf:
Hi!
Well, we are not trying to get to 0 failed tests in all permutations of
all extensions on all platforms. We are trying to get to 0 failed tests
on a common-case build using defaults and common extensions. Given that,
changing a default has an impact on the 0-failed-tests goal.Nobody talks about "all permutations of all platforms", let's not be
absurd here. However, there's a distance between "all permutations of
all platforms" and "we'll be ignoring failures on libmysql". libmysql
is the common case build and the one most people would be running in
production, at least as far as I see around.Ah yes, but is that because they have actively chosen to use libmysql or
is it because our default is libmysql. It is buggier and less robust
than mysqlnd at this point, at least in my experience, so who are we
helping by leaving libmysql as the default?
ACK.
Yes, it is about the default that others copy from php.net.
(Yes, I consider mysqlnd stability to be at least on par with the
libmysql and, mysqlnd is usually getting much faster bug fixes. Together
with the set of free PHP license plugins (pecl/mysqlnd_*, query cache,
replication support, load balancing, monitoring, ...),
asynchronous/non-blocking queries, a nice debug trace log, copy-on-write
variables, recognition of PHP's memory limit, ... it is worth a
recommendation to users. Time to spread the news by switching the
compile default. Five years after development started, four years after
alpha and beta. Plus the PHP 5.3-series as an "incubation" time.)
Forget the failed tests. A new PHP release is about improving the
ecosystem. If the folks that maintain libmysql and mysqlnd suggest that
mysqlnd is more robust and it is the path forward, why would we resist
this? Do we not trust Oracle/MySQL enough to listen to their input?
ACK.
(For the last time in this thread: there are no plans to remove libmysql
support but mysqlnd is the recommended choice.)
Ulf
Hi!
Forget the failed tests. A new PHP release is about improving the
ecosystem. If the folks that maintain libmysql and mysqlnd suggest that
mysqlnd is more robust and it is the path forward, why would we resist
this? Do we not trust Oracle/MySQL enough to listen to their input?
Because of the little thing called BC? Right now I have at least two
tests suggesting mysqlnd has different semantics than libmysql, and not
in some obscure corners either but in functions most people use every
day in every piece of code. This is worrying.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Am 04.09.2011 06:37, schrieb Stas Malyshev:
Hi!
Forget the failed tests. A new PHP release is about improving the
ecosystem. If the folks that maintain libmysql and mysqlnd suggest that
mysqlnd is more robust and it is the path forward, why would we resist
this? Do we not trust Oracle/MySQL enough to listen to their input?Because of the little thing called BC?
what the hell are you speaking about?
again:
running some hundret domains and made the switch to PHP 5.3 AND mysqlnd
at once, no single problem - there are no differences in the real world
and yes we are running ALL servers with error_reporting E_ALL | E_STRICT
Right now I have at least two tests suggesting mysqlnd has different
semantics than libmysql,
so why are these not reported upstream 1 year ago and fixed?
and not in some obscure corners either but in functions most people use every day in every
piece of code. This is worrying
- last_insert_id semantics change. The test expects select queries to reset last insert
it to 0, which does not happen with libmysql. Maybe it happens on later versions of mysql
server, I do not know
mhh in the real world some function makes the insert and giving back the ID
this maybe only relevant in spaghetti code and even there you fetch the
insertid after the insert and not 2000 lines later
Hi!
again:
running some hundret domains and made the switch to PHP 5.3 AND mysqlnd
at once, no single problem - there are no differences in the real world
That's assuming "real world" is exclusively your experience. In the
meantime, outside of this "real world" I just sent to the list two
examples where mysqlnd semantics as assumed by tests appears to be
different from libmysql.
so why are these not reported upstream 1 year ago and fixed?
I don't know why. Why indeed? Why we have tests that fail and nobody
fixed them 1 year ago or asked why they fail? I have no good answer to
that, sorry. Do you?
But while this may be very curious, the real question is - how we fix it
now?
mhh in the real world some function makes the insert and giving back the ID
this maybe only relevant in spaghetti code and even there you fetch the
insertid after the insert and not 2000 lines later
By "real world" you again must be meaning exclusively your code. Let me
be the first to congratulate you that your code won't be affected.
However the point of BC is not to be compatible exclusively with your
code, other code matters too. Including the code you may not like.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas,
What are you actually afraid of?
Libmysql will still be supported. Mysqlnd, despite your examples, work out
of a bix with all major apps and frameworks out there. We do test it using
drupal 6&7, wp, oscommerce, mediawiki, sugarcrm, etc since 5.3.0. We have
zero compatibility.
In short, I do not understand your opposition.
Hi!
again:
running some hundret domains and made the switch to PHP 5.3 AND mysqlnd
at once, no single problem - there are no differences in the real worldThat's assuming "real world" is exclusively your experience. In the
meantime, outside of this "real world" I just sent to the list two
examples where mysqlnd semantics as assumed by tests appears to be
different from libmysql.so why are these not reported upstream 1 year ago and fixed?
I don't know why. Why indeed? Why we have tests that fail and nobody
fixed them 1 year ago or asked why they fail? I have no good answer to
that, sorry. Do you?
But while this may be very curious, the real question is - how we fix it
now?mhh in the real world some function makes the insert and giving back the
ID
this maybe only relevant in spaghetti code and even there you fetch the
insertid after the insert and not 2000 lines laterBy "real world" you again must be meaning exclusively your code. Let me
be the first to congratulate you that your code won't be affected.
However the point of BC is not to be compatible exclusively with your
code, other code matters too. Including the code you may not like.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
What are you actually afraid of?
Having two different semantics inside one mysql extension.
Libmysql will still be supported. Mysqlnd, despite your examples, work
out of a bix with all major apps and frameworks out there. We do test it
Do you really think "but it works for me" is of any value when there's
an example where it does not?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Am 04.09.2011 12:22, schrieb Stas Malyshev:
Hi!
What are you actually afraid of?
Having two different semantics inside one mysql extension.
so these have to be cleaned up
Libmysql will still be supported. Mysqlnd, despite your examples, work
out of a bix with all major apps and frameworks out there. We do test itDo you really think "but it works for me" is of any value when there's an example where it does not?
for a release like PHP 5.4 witch the chance to cleanup some thing
SURELY
and again: targeting mysqlnd as default in 5.4 maybe the missing reason
for cleanup / fixup the code so that the tests will run finally
Am 04.09.2011 11:33, schrieb Stas Malyshev:
Hi!
again:
running some hundret domains and made the switch to PHP 5.3 AND mysqlnd
at once, no single problem - there are no differences in the real worldThat's assuming "real world" is exclusively your experience. In the meantime, outside of this "real world" I just
sent to the list two examples where mysqlnd semantics as assumed by tests appears to be different from libmysql.so why are these not reported upstream 1 year ago and fixed?
I don't know why. Why indeed? Why we have tests that fail and nobody fixed them 1 year ago or asked why they fail?
I have no good answer to that, sorry. Do you?
But while this may be very curious, the real question is - how we fix it now?mhh in the real world some function makes the insert and giving back the ID
this maybe only relevant in spaghetti code and even there you fetch the
insertid after the insert and not 2000 lines laterBy "real world" you again must be meaning exclusively your code. Let me be the first to congratulate you that your
code won't be affected. However the point of BC is not to be compatible exclusively with your code, other code
matters too. Including the code you may not like
i do not like wordpress and joomla, but both runnign with mysqlnd without troubles
only error_reporting must be a little bit changed because the bad code quality
2011.09.04 12:13 Reindl Harald rašė:
Am 04.09.2011 06:37, schrieb Stas Malyshev:
Hi!
Forget the failed tests. A new PHP release is about improving the
ecosystem. If the folks that maintain libmysql and mysqlnd suggest that
mysqlnd is more robust and it is the path forward, why would we resist
this? Do we not trust Oracle/MySQL enough to listen to their input?Because of the little thing called BC?
what the hell are you speaking about?
A little thing called backwards compatibility. If you change the way
extension behaves and some application depends on that kind of behavior,
it will break that application.
Right now I have at least two tests suggesting mysqlnd has different
semantics than libmysql,so why are these not reported upstream 1 year ago and fixed?
Since when third party implementation can impose own standards on primary
library implementation? Different semantics is not a bug for libmysql.
--
Tomas
Am 04.09.2011 11:54, schrieb Tomas Kuliavas:
2011.09.04 12:13 Reindl Harald rašė:
Am 04.09.2011 06:37, schrieb Stas Malyshev:
Hi!
Forget the failed tests. A new PHP release is about improving the
ecosystem. If the folks that maintain libmysql and mysqlnd suggest that
mysqlnd is more robust and it is the path forward, why would we resist
this? Do we not trust Oracle/MySQL enough to listen to their input?Because of the little thing called BC?
what the hell are you speaking about?
A little thing called backwards compatibility. If you change the way
extension behaves and some application depends on that kind of behavior,
it will break that application.
well but mysqlnd is not new and well tested in the wild
the only problem is that libmysql-support was not removed with
the first 5.3 version, so we would have no discussion now
Right now I have at least two tests suggesting mysqlnd has different
semantics than libmysql,so why are these not reported upstream 1 year ago and fixed?
Since when third party implementation can impose own standards on primary
library implementation? Different semantics is not a bug for libmysql
AFAIK was mysqlnd also from sun/mysqlab/oracle
anyways - the only thing what is intereresting me why in the world are
failing tests ignored over years and the more or less broken code
or if the code is not broken the test himslef not fixed
why in the world does php permanently introduce redundances and
never cleanup them?
"mysql_escape_string" and "mysql_real_escape_string" is the best example
now we have libmysql, mysqlnd and both used by mysql_* and mysqli_* instead
release PHP 5.3 with removing mysql_*-functions and only msqlnd
how long do we not have these ballast as everybody can see by for long times failing
tests not really maintained
my main-question is for what reason are tests introduced if nobofy caers about them
for months and years? problems without any tests are hapenning and the reason
for making tests, but ignoring failed tests is simply stupid - everywhere independent
if we are speaking about opensource or commercial software
Stas Malyshev wrote:
libmysql is the common case build and the one most people would be running in
production, at least as far as I see around.
In the words of wikipedia - provide proof.
If this is the case then why is mysqlnd loaded by default? Even if we do not
have MySQL installed.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Stas Malyshev wrote:
libmysql is the common case build and the one most people would be
running in
production, at least as far as I see around.
In the words of wikipedia - provide proof.
If this is the case then why is mysqlnd loaded by default? Even if we do
not have MySQL installed.
Lester, it would really help if you added "on Windows" to the end of all
your messages so you don't confuse the rest of us who are not talking
about Windows at all. We are talking about the configure flags on UNIX.
mysqlnd is only loaded by default in the binary build on Windows.
-Rasmus
Rasmus Lerdorf wrote:
Stas Malyshev wrote:
libmysqlis the common case build and the one most people would be
running in
production, at least as far as I see around.
In the words of wikipedia - provide proof.
If this is the case then why is mysqlnd loaded by default? Even if we do
not have MySQL installed.
Lester, it would really help if you added "on Windows" to the end of all
your messages so you don't confuse the rest of us who are not talking
about Windows at all. We are talking about the configure flags on UNIX.
mysqlnd is only loaded by default in the binary build on Windows.
See other post!
I am documenting and supporting FLAP just as much as FWAP ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hi!
One of the goals before the beta is to get to 0 failed tests for a
common build. Unless you simply skip all the failing libmysql tests,
that's going to be hard to do unless we move the default to a more
robust library. That doesn't mean we shouldn't fix all the weirdHow moving default changes anything?
Well, we are not trying to get to 0 failed tests in all permutations of
all extensions on all platforms. We are trying to get to 0 failed tests
on a common-case build using defaults and common extensions. Given that,
changing a default has an impact on the 0-failed-tests goal.
-Rasmus
Rasmus Lerdorf wrote:
I was actually going to suggest doing this in 5.4 and trunk but didn't
get around to writing the email yet.
It would still be nice to be able to simply switch off MySQL for those of us who
do not have it installed ...
It gets annoying when PHP forces the installation of MySQL in a distribution and
then prevents disabling it. It is another example of why a more modular approach
does make sense!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Am 02.09.2011 22:17, schrieb Lester Caine:
Rasmus Lerdorf wrote:
I was actually going to suggest doing this in 5.4 and trunk but didn't
get around to writing the email yet.It would still be nice to be able to simply switch off MySQL for those
of us who do not have it installed ...
It gets annoying when PHP forces the installation of MySQL in a
distribution and then prevents disabling it. It is another example of
why a more modular approach does make sense!
Lester,
do I understand that you are afraid of a PHP which comes with MySQL
support that cannot be disabled?
I don't think the proposal goes like that. The proposal is to change the
default library, if not set during compile, used by the MySQL
extensions, if enabled, from libmysql to mysqlnd. This is independent of
the questions:
- if any MySQL extension shall be enabled by default
- if PHP can be built without MySQL support
And, I said it in the other email, this is no attempt to remove libmysql
support.
I may be wrong but your concern - as valid as it is - seems a bit off
topic, no?
Ulf
Ulf Wendel wrote:
Am 02.09.2011 22:17, schrieb Lester Caine:
Rasmus Lerdorf wrote:
I was actually going to suggest doing this in 5.4 and trunk but didn't
get around to writing the email yet.It would still be nice to be able to simply switch off MySQL for those
of us who do not have it installed ...
It gets annoying when PHP forces the installation of MySQL in a
distribution and then prevents disabling it. It is another example of
why a more modular approach does make sense!Lester,
do I understand that you are afraid of a PHP which comes with MySQL support that
cannot be disabled?I don't think the proposal goes like that. The proposal is to change the default
library, if not set during compile, used by the MySQL extensions, if enabled,
from libmysql to mysqlnd. This is independent of the questions:
- if any MySQL extension shall be enabled by default
- if PHP can be built without MySQL support
And, I said it in the other email, this is no attempt to remove libmysql support.
I may be wrong but your concern - as valid as it is - seems a bit off topic, no?
If the MySQL support was loaded as an extension rather than being forced on
everybody, then you could provide either version of library just by selecting
the right extension? Just as we provide special builds of other extensions to
allow backwards compatibility ... we HAD dropped MySQL dependence at one point,
but it seems to have crept back in without any particular agreement?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Rasmus Lerdorf wrote:
I was actually going to suggest doing this in 5.4 and trunk but didn't
get around to writing the email yet.It would still be nice to be able to simply switch off MySQL for those
of us who do not have it installed ...
It gets annoying when PHP forces the installation of MySQL in a
distribution and then prevents disabling it. It is another example of
why a more modular approach does make sense!
I have no idea what you mean. We don't force MySQL in any way.
If you grab the PHP code and do: ./configure && make
there is absolutely no MySQL. You have to explictly do --with-mysql to
get MySQL support just like you have to enable other non-default extensions.
What the Oracle/MySQL guys are suggesting is simply that when you do
specify --with-mysql the default should be mysqlnd.
-Rasmus
Rasmus Lerdorf wrote:
Rasmus Lerdorf wrote:
I was actually going to suggest doing this in 5.4 and trunk but didn't
get around to writing the email yet.It would still be nice to be able to simply switch off MySQL for those
of us who do not have it installed ...
It gets annoying when PHP forces the installation of MySQL in a
distribution and then prevents disabling it. It is another example of
why a more modular approach does make sense!
I have no idea what you mean. We don't force MySQL in any way.
If you grab the PHP code and do: ./configure&& make
there is absolutely no MySQL. You have to explictly do --with-mysql to
get MySQL support just like you have to enable other non-default extensions.What the Oracle/MySQL guys are suggesting is simply that when you do
specify --with-mysql the default should be mysqlnd.
All builds seem to have mysqlnd included by default? So that has to be tested on
every installation even if it's not going to be used? And I've hit problems with
distributions needing MySQL because of a dependency on mysqlnd.
I know we have had the discussion before, but if it is a general library for all
databases then call it something else, if it's specific for MySQL then it only
needs to be installed when MySQL is available on a system?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
All builds seem to have mysqlnd included by default? So that has to be
tested on every installation even if it's not going to be used? And I've
hit problems with distributions needing MySQL because of a dependency on
mysqlnd.I know we have had the discussion before, but if it is a general library
for all databases then call it something else, if it's specific for
MySQL then it only needs to be installed when MySQL is available on a
system?
Which general library? We are talking about mysqlnd which is obviously
only for MySQL.
And what do you mean by "all builds" ?
We don't do builds, the distributions do builds and we can't really
control what they choose to include by default, but most of the ones I
have seen have a separate php-mysql package.
I guess you may be exclusively talking about Windows builds and that has
absolutely nothing to do with our current discussion of whether
--with-mysql should point to libmysql or libmysqlnd by default.
-Rasmus
Rasmus Lerdorf wrote:
All builds seem to have mysqlnd included by default? So that has to be
tested on every installation even if it's not going to be used? And I've
hit problems with distributions needing MySQL because of a dependency on
mysqlnd.I know we have had the discussion before, but if it is a general library
for all databases then call it something else, if it's specific for
MySQL then it only needs to be installed when MySQL is available on a
system?Which general library? We are talking about mysqlnd which is obviously
only for MySQL.And what do you mean by "all builds" ?
We don't do builds, the distributions do builds and we can't really
control what they choose to include by default, but most of the ones I
have seen have a separate php-mysql package.I guess you may be exclusively talking about Windows builds and that has
absolutely nothing to do with our current discussion of whether
--with-mysql should point to libmysql or libmysqlnd by default.
My SUSE installs all have mysqlnd included in the core, As do other Linux
distributions. I think for much the same reason that the windows builds do as
well? The PHP development team have decided that -without-mysqlnd is required to
remove it rather than -with-mysqlnd is with other optional packages. THAT
decision determines what the distributions all do and flags mysqlnd as a core
package?
Since I have no interest in MySQL much of this is academic other than having to
manage the fallout, so the bit I'm not understanding here is where mysqlnd fits
in with libmysql or libmysqlnd. Is mysqlnd even used by mysql if libmysql is the
default library?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
My SUSE installs all have mysqlnd included in the core, As do other
Linux distributions. I think for much the same reason that the windows
builds do as well? The PHP development team have decided that
-without-mysqlnd is required to remove it rather than -with-mysqlnd is
with other optional packages. THAT decision determines what the
distributions all do and flags mysqlnd as a core package?
But I just told you that wasn't the case. Try it yourself. Download the
PHP tarball on your SUSE box and do ./configure && make
Show me where mysqlnd is linked in. It isn't.
-Rasmus