Hi,
On 09/07/2011 07:17 AM, Tomas Kuliavas wrote:
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 "incubati
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 se
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 mysqln
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 co
Am 05.09.2011 11:08, schrieb Stas Malyshev:
Hi!
On 9/5/11 1:24 AM, Andrey Hristov wrote:
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
Am 05.09.2011 11:08, schrieb Stas Malyshev:
> Hi!
>
> On 9/5/11 1:24 AM, Andrey Hristov wrote:
>> 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:
>
>
Hi!
On 9/5/11 1:24 AM, Andrey Hristov wrote:
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
Hi Stas,
On 09/02/2011 10:44 PM, Stas Malyshev wrote:
Hi!
On 9/2/11 1:41 PM, Ferenc Kovacs wrote:
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
On Sun, Sep 4, 2011 at 7:59 PM, Reindl Harald wrote:
>
>
> Am 04.09.2011 19:52, schrieb Stas Malyshev:
>
>>> There are incimoatibilities too across libmysql versions and across
>>> mysql servers, which are actually affecting existing codes.
>>
>> I don't know of any incompatibilities that change s
Am 04.09.2011 19:52, schrieb Stas Malyshev:
>> There are incimoatibilities too across libmysql versions and across
>> mysql servers, which are actually affecting existing codes.
>
> I don't know of any incompatibilities that change semantics on this level,
> and anyway libmysql is beyond our c
On Sun, Sep 4, 2011 at 8:08 PM, Stas Malyshev wrote:
>> No, just like what I said for the is_a change, but it was acceptable
>> for is_a, right? is_a actually broken many (many) apps and codes out
>> there and it was easily identified, and it was even acceptable in a
>> patch release. Go figure.
Hi!
On 9/4/11 10:59 AM, Pierre Joye wrote:
No, just like what I said for the is_a change, but it was acceptable
for is_a, right? is_a actually broken many (many) apps and codes out
there and it was easily identified, and it was even acceptable in a
patch release. Go figure.
Please do not drag
hi,
On Sun, Sep 4, 2011 at 7:52 PM, Stas Malyshev wrote:
> So you're saying breaking BC is OK if only you can find some unaffected
> applications, right?
No, just like what I said for the is_a change, but it was acceptable
for is_a, right? is_a actually broken many (many) apps and codes out
the
Hi!
On 9/4/11 3:43 AM, Pierre Joye wrote:
It is not "works for me" but what actually represent a very large amount
of the running php codes out there.
So you're saying breaking BC is OK if only you can find some unaffected
applications, right?
There are incimoatibilities too across libmysq
Can you please open you eyes a little bit so we can move fordward in this
simehow sterile discussion?
It is not "works for me" but what actually represent a very large amount of
the running php codes out there.
There are incimoatibilities too across libmysql versions and across mysql
servers, whi
Am 04.09.2011 12:22, schrieb Stas Malyshev:
> Hi!
>
> On 9/4/11 2:38 AM, Pierre Joye wrote:
>> 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, wo
Hi!
On 9/4/11 2:38 AM, Pierre Joye wrote:
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 reall
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!
>>>
>>> On 9/2/11 6:51 PM, Rasmus Lerdorf wrote:
Forget the failed tests. A new PHP release is about improving the
ecosystem. If the folks tha
2011.09.04 12:13 Reindl Harald rašė:
>
>
> Am 04.09.2011 06:37, schrieb Stas Malyshev:
>> Hi!
>>
>> On 9/2/11 6:51 PM, Rasmus Lerdorf wrote:
>>> Forget the failed tests. A new PHP release is about improving the
>>> ecosystem. If the folks that maintain libmysql and mysqlnd suggest that
>>> mysqlnd
Am 04.09.2011 11:33, schrieb Stas Malyshev:
> Hi!
>
> On 9/4/11 2:13 AM, Reindl Harald wrote:
>> 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 exclu
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 d
Hi!
On 9/4/11 2:13 AM, Reindl Harald wrote:
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 "rea
Am 04.09.2011 06:37, schrieb Stas Malyshev:
> Hi!
>
> On 9/2/11 6:51 PM, Rasmus Lerdorf wrote:
>> 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
Hi!
On 9/2/11 6:51 PM, Rasmus Lerdorf wrote:
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
Am 03.09.2011 03:51, schrieb Rasmus Lerdorf:
On 09/02/2011 06:08 PM, Stas Malyshev wrote:
Hi!
On 9/2/11 6:02 PM, Rasmus Lerdorf wrote:
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-cas
On 09/03/2011 12:15 AM, Lester Caine wrote:
> 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 rath
Rasmus Lerdorf wrote:
On 09/02/2011 11:48 PM, Lester Caine wrote:
> 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 cas
Rasmus Lerdorf wrote:
On 09/02/2011 11:43 PM, Lester Caine 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 k
On 09/02/2011 11:48 PM, Lester Caine wrote:
> 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 d
On 09/02/2011 11:43 PM, Lester Caine 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 h
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.
--
Le
Rasmus Lerdorf wrote:
On 09/02/2011 01:17 PM, Lester Caine 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 wh
On 09/02/2011 06:08 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/2/11 6:02 PM, Rasmus Lerdorf wrote:
>> 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
Hi Folks:
On Fri, Sep 02, 2011 at 06:08:59PM -0700, Stas Malyshev wrote:
> 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
Am 03.09.2011 03:08, schrieb Stas Malyshev:
> Hi!
>
> On 9/2/11 6:02 PM, Rasmus Lerdorf wrote:
>> 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
Hi!
On 9/2/11 6:02 PM, Rasmus Lerdorf wrote:
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 o
On 09/02/2011 05:56 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/2/11 4:45 PM, Rasmus Lerdorf wrote:
>> 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
On 09/02/2011 05:56 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/2/11 4:45 PM, Rasmus Lerdorf wrote:
>> 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
Hi!
On 9/2/11 4:45 PM, Rasmus Lerdorf wrote:
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 f
On 09/02/2011 01:17 PM, Lester Caine 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 ...
On 09/02/2011 12:24 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/2/11 12:17 PM, Christopher Jones wrote:
>> 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
Hi!
On 9/2/11 2:51 PM, Ulf Wendel wrote:
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
2011/9/2 Stas Malyshev :
> Hi!
>
> On 9/2/11 1:14 PM, Johannes Schlüter wrote:
>>
>> 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
Am 02.09.2011 23:30, schrieb Stas Malyshev:
Hi!
On 9/2/11 2:12 PM, Ulf Wendel wrote:
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
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 instal
Hi!
On 9/2/11 2:12 PM, Ulf Wendel wrote:
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 pas
Am 02.09.2011 23:20, schrieb Stas Malyshev:
Hi!
On 9/2/11 1:57 PM, Johannes Schlüter wrote:
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 wh
Hi!
On 9/2/11 1:57 PM, Johannes Schlüter wrote:
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
Am 02.09.2011 22:57, schrieb Johannes Schlüter:
On Fri, 2011-09-02 at 22:48 +0200, Ferenc Kovacs wrote:
On Fri, Sep 2, 2011 at 10:44 PM, Stas Malyshev wrote:
Hi!
On 9/2/11 1:41 PM, Ferenc Kovacs wrote:
I think you missed the referenced [1]:
[1] Yes, we will still allow building with libmys
On Fri, 2011-09-02 at 22:48 +0200, Ferenc Kovacs wrote:
> On Fri, Sep 2, 2011 at 10:44 PM, Stas Malyshev wrote:
> > Hi!
> >
> > On 9/2/11 1:41 PM, Ferenc Kovacs wrote:
> >>
> >> I think you missed the referenced [1]:
> >>
> >> [1] Yes, we will still allow building with libmysql and we will fix bug
On Fri, Sep 2, 2011 at 10:44 PM, Stas Malyshev wrote:
> Hi!
>
> On 9/2/11 1:41 PM, Ferenc Kovacs wrote:
>>
>> 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
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 ann
Hi!
On 9/2/11 1:41 PM, Ferenc Kovacs wrote:
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 w
2011/9/2 Stas Malyshev :
> Hi!
>
> On 9/2/11 1:14 PM, Johannes Schlüter wrote:
>>
>> 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
Hi!
On 9/2/11 1:14 PM, Johannes Schlüter wrote:
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 equ
On Fri, 2011-09-02 at 12:24 -0700, Stas Malyshev wrote:
> Hi!
>
> On 9/2/11 12:17 PM, Christopher Jones wrote:
> > 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
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 M
+1 and agree that it should be implemented before the beta.
On Fri, Sep 2, 2011 at 2:58 PM, Ulf Wendel wrote:
> Am 02.09.2011 21:24, schrieb Stas Malyshev:
>
> Hi!
>>
>> On 9/2/11 12:17 PM, Christopher Jones wrote:
>>
>>> I'm +1 for this. I think the decision& implementation needs to be done
Am 02.09.2011 21:24, schrieb Stas Malyshev:
Hi!
On 9/2/11 12:17 PM, Christopher Jones wrote:
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
On 09/02/2011 12:24 PM, Stas Malyshev wrote:
Hi!
On 9/2/11 12:17 PM, Christopher Jones wrote:
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. be
Hi!
On 9/2/11 12:17 PM, Christopher Jones wrote:
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
On 09/02/2011 08:32 AM, Rasmus Lerdorf wrote:
On 09/02/2011 05:27 AM, Johannes Schlüter wrote:
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
forgot to include everyone on this response - sorry.
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 --wit
On 09/02/2011 05:27 AM, Johannes Schlüter wrote:
> 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 --w
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
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-reaso
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
67 matches
Mail list logo
