Pierre Joye schrieb:
Tell us the names of these entities, companies or persons, who are
going to contribute and what are actually their requirements. What
will they bring (saying expertise is not something I can buy)? I
don't understand what is so hard to understand that it is a minimum to
get
Lars Strojny schrieb:
Hi Lukas, hi Johannes,
Am Freitag, den 11.07.2008, 11:59 +0200 schrieb Lukas Kahwe Smith:
- MySQLnd
what's with PDO MySQLnd, will it be part of 5.3?
The PDO_MYSQLND extension, as I call it, is a patched PDO_MYSQL
extension. PDO_MYSQLND is on the TODO list [1].
I
Lukas Kahwe Smith schrieb:
On 14.07.2008, at 11:29, Ulf Wendel wrote:
Lars Strojny schrieb:
Hi Lukas, hi Johannes,
Am Freitag, den 11.07.2008, 11:59 +0200 schrieb Lukas Kahwe Smith:
- MySQLnd
what's with PDO MySQLnd, will it be part of 5.3?
[snip]
Johannes is working on a 3-stars
Jani Taskinen schrieb:
Ulf Wendel wrote:
We did a tough development sprint in the last weeks to make the patch
ready for the tentative PHP 5.3 release plan. Our internal release
plan shows no coding between Beta and GA but fixing newly reported bugs.
What about the already reported (a.k.a
Jani Taskinen schrieb:
Well, connection issues using mysqlnd seems to be pretty commonly
reported, like this:
http://bugs.php.net/45468
Aaah, you're talking about mysqlnd @ ext/mysql[i] - different story
altogether.
There are 20 open reports currently:
Lukas Kahwe Smith schrieb:
there are also a few in PECL:
http://pecl.php.net/bugs/search.php?cmd=displaystatus=Openpackage_name[]=PDO_mysql
Ok, that's PDO_MYSQL. We checked both pecl.php.net and php.net bug
lists. Are there any plans to improve the PHP bug systems to allow:
- prioritizing
Hi Lars!
Lars Strojny schrieb:
Is there a way to checkout the source. I would love to test PDO_MYSQLND.
Not yet. Andrey will need a day or so. I've CC'd him. He can post
instructions here.
The internal mysqlnd repostory, which includes the code for PDO_MYSQLND,
was among the first to be
Pierre Joye schrieb:
Drop the launchpad and use php's cvs. We have actually two development
branches (5.3 until the 24th and HEAD) and PECL. The latter let you
experiment as much as you wish.
Pierre, you are not in the position to tell us what repository we use
for internal developments and
Pierre Joye schrieb:
On Tue, Jul 15, 2008 at 5:42 PM, Ulf Wendel [EMAIL PROTECTED] wrote:
What's your point, what requests are you talking about?
Please ask Johannes, I told them to him live last time we met. If
there is doubts, I will happily repeat them.
So, you have one question related
Pierre Joye schrieb:
On Tue, Jul 15, 2008 at 7:05 PM, Ulf Wendel [EMAIL PROTECTED] wrote:
Pierre Joye schrieb:
On Tue, Jul 15, 2008 at 5:42 PM, Ulf Wendel [EMAIL PROTECTED] wrote:
What's your point, what requests are you talking about?
Please ask Johannes, I told them to him live last time
Marcus Boerger schrieb:
Tuesday, July 15, 2008, 4:32:10 PM, you wrote:
Pierre Joye schrieb:
Drop the launchpad and use php's cvs. We have actually two development
branches (5.3 until the 24th and HEAD) and PECL. The latter let you
experiment as much as you wish.
Pierre, you are not in the
Derick Rethans schrieb:
On Tue, 15 Jul 2008, Andrey Hristov wrote:
I am pretty lazy, thus I use my Thunderbird as a RSS reader. I get
planetmysql as a feed and if I am not interested in an article, I skip
it. It doesn't require even to go anymore to planetmysql . But even
more, Ulf is also
Pierre Joye schrieb:
On Wed, Jul 16, 2008 at 6:13 PM, Ulf Wendel [EMAIL PROTECTED] wrote:
Derick Rethans schrieb:
On Tue, 15 Jul 2008, Andrey Hristov wrote:
I am pretty lazy, thus I use my Thunderbird as a RSS reader. I get
planetmysql as a feed and if I am not interested in an article, I
Pierre Joye schrieb:
hi,
On Wed, Jul 16, 2008 at 7:27 PM, Ulf Wendel [EMAIL PROTECTED] wrote:
What improvements or RFC's did I blog about instead of sending them to the
PHP development list. Its just not obvious to me.
No idea, and that's the problem. I do read the bug reports, not your
Lester Caine schrieb:
Ulf Wendel wrote:
If mysqlnd turns out to be stable enough during the PHP 5.3 test
phase, PHP 5.3+ may use mysqlnd as a default. There is no need to
download an extra library when using 5.3.
Lukas, this is not affecting PHP 5.3 as long as mysqlnd is
stable/fast
Moin Marcus!
Marcus Boerger schrieb:
to be honest this is the wrong way. The correct way of fixing this is to
have PHP 6 name it correct: string and binary. And to have b for binary
prefix rather then u for unicode. Or did PHP 6 change in the meanwhile and
we support uNonsense besides
Marcus Boerger schrieb:
to be honest this is the wrong way. The correct way of fixing this is to
have PHP 6 name it correct: string and binary. And to have b for binary
Aside from the question of how to write a portable test, here is an
example speaking for your argument of making a
Stanislav Malyshev schrieb:
I notice that mysql_set_charset function is not part of 5.3 tree and
it's test is marked as usage not recommended. Could you explain what
is the reason for that? It's quite unusual to drop functions in later
versions, and if mysql_set_charset() has some problem we
Ulf Wendel schrieb:
and its in HEAD. Andrey is working on re-introducing it to ext/mysql in
the 5_3 branch.
There it is http://news.php.net/php.cvs/52063
Ulf
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Ulf Wendel schrieb:
I don't recall why I added usage not recommended to the test. Let me
check with Georg. He had some concerns on the function as far as I
remember.
I checked with Georg. My memories regarding Georg's position are totally
wrong. He once introduced mysql_set_charset
Hi!
Based on some discussions with Facebook, Tuenti and Andrey we have
developed an unofficial MySQL Server patch. Furthermore we have added
a new function to ext/mysqli which only purpose is to access
functionality available only with a patched MySQL Server. Therefore we
have not committed
William A. Rowe, Jr. schrieb:
Well, the binaries probably include c runtimes under liberal MS license.
They might be kind and give you mysql and a host of other GPL features under
a very restrictive license.
With any PHP before 5.3, you'll have to compile any of the MySQL
extensions
Ionut G. Stan schrieb:
Warning: mysql_connect() [function.mysql-connect]: OK packet 6 bytes
shorter than expected in {filename} on line 18
Warning: mysql_connect() [function.mysql-connect]: mysqlnd cannot
connect to MySQL 4.1+ using old authentication in {filename} on line 18
This says
Jani Taskinen schrieb:
Pierre Joye kirjoitti:
Hi,
Would it not easier and better to have mysqlnd as default backend for
the mysql extensions (pdo, mysqli and mysql) when the configure option
are used without value? I can already imagine the maintenance pains
and the debugging nightmare for our
Remi Collet schrieb:
My goal will be to provides both solutions (libmysql and mysqlnd) to be
able to quickly switch from one to the other (for tests / benchmark)
Any idea / solution ?
Andrey might have. CC'ing him.
P.S. main question is probably, should we use mysqlnd under linux ?
.
Only ext/mysqli gives you access to all functionality of MySQL 4.1 and
above, e.g. charset and prepared statements.
I see no reasons for updating ext/mysql when there is a successor (for
so long).
Ulf
--
Ulf Wendel, MySQL
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim
.
ext/mysql already hides functionality, for example, prepared
statements. If you add all the missing pieces to ext/mysql you get
ext/mysqli...
Ulf
--
Ulf Wendel, MySQL
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr
(which means officially
supported) I see no reason to reject simple patches
Definetly -1 from my side: what maked warning count different from
prepared statements?
If ext/mysql would not have such a tremendous user base, I would even
suggest to disable it by default.
Ulf
--
Ulf Wendel
Am 11.2012 14:00, schrieb Adam Harvey:
I've written an RFC to cover deprecating ext/mysql in PHP 5.5:
https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft
deprecation in the documentation purely via a straw poll on Internals,
I presume this will end up needing to go to a vote,
Am 12.11.2012 15:48, schrieb Antony Dovgal:
On 2012-11-12 18:15, Adam Harvey wrote:
I don't think the documentation is necessarily effective here,
particularly with functions that users tend to know by heart
skip
I'm not really convinced the average user ever looks at the manual for
things
Am 16.11.2012 03:23, schrieb Sherif Ramadan:
People have been talking about and educating others about the
deprecation of ext/mysql for quite some time now. I'm sure that it
Random dates in the lifes of ext/mysql[i]:
2003
* ext/mysqli, the improved version of ext/mysql gets developed
*
Am 13.11.2012 04:08, schrieb Adam Harvey:
On 13 November 2012 08:44, Christopher Jones
christopher.jo...@oracle.com wrote:
Adam, can you:
1. Add this link to the RFC?:
https://wikis.oracle.com/display/mysql/Converting+to+MySQLi
As the author I cannot recommend materials created in
Am 20.11.2012 11:22, schrieb Lester Caine:
Ulf Wendel wrote:
1. Add this link to the RFC?:
https://wikis.oracle.com/display/mysql/Converting+to+MySQLi
As the author I cannot recommend materials created in 2006 and not
updated since then for inclusion into a RFC.
At the end
Am 20.11.2012 13:25, schrieb Lester Caine:
Ulf Wendel wrote:
Am 20.11.2012 11:22, schrieb Lester Caine:
Ulf Wendel wrote:
1. Add this link to the RFC?:
https://wikis.oracle.com/display/mysql/Converting+to+MySQLi
As the author I cannot recommend materials created in 2006 and not
updated
Am 12.02.2013 12:51, schrieb Asbjørn Sannes:
https://wiki.php.net/rfc/mysqlnd_localhost_override
I propose we introduce a new option called mysqlnd.localhost_override
which enables a system administrator or php distributor to configure how
localhost should be overridden.
localhost meaning is
Am 12.02.2013 13:11, schrieb Johannes Schlüter:
On Tue, 2013-02-12 at 12:51 +0100, Asbjørn Sannes wrote:
https://wiki.php.net/rfc/mysqlnd_localhost_override
I propose we introduce a new option called mysqlnd.localhost_override
which enables a system administrator or php distributor to
Am 18.08.2011 00:46, schrieb Reindl Harald:
Wouldn't it be a good idea to specify here a user/pwd/database for
build-systems without force them open root without password?
SKIP mysql_get_host_info() [ext/mysql/tests/mysql_get_host_info.phpt] reason:
Can't connect to MySQL Server -
[1045]
Am 19.08.2011 13:12, schrieb Jonathan Bond-Caron:
On Thu Aug 4 09:54 PM, Raymond Irving wrote:
Hello,
I came across this little library called TameJS (http://tamejs.org/)
and fell in love with the it's syntax. This had me thinking if it was
possible to add such features to a PHP CLI (or web
Am 02.09.2011 19:19, schrieb Stas Malyshev:
My environment is Mac OS X, libmysql version 5.1.46 (yes, I know it's
old, but that's what is out there in production for many, so we have to
support it).
Stas,
please, always test against the latest and greatest. Otherwise you'll be
testing
Am 02.09.2011 20:27, schrieb Stas Malyshev:
On 9/2/11 11:03 AM, Ulf Wendel wrote:
please, always test against the latest and greatest. Otherwise you'll be
testing against libmysql versions that are not going to see any updates.
5.1 is still a supported version of Mysql. It is run on many
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
Am 02.09.2011 22:07, schrieb Stas Malyshev:
Hi!
On 9/2/11 12:11 PM, Ulf Wendel wrote:
This is no more than a friendly request to check against latest and
greatest to avoid hitting bugs already fixed in libmysql. Latest GA is
5.1.58, if I'm not mistaken,
http://dev.mysql.com/downloads/mysql/5.1
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
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 Malyshevsmalys...@sugarcrm.com wrote:
Hi!
On 9/2/11 1:41 PM, Ferenc Kovacs wrote:
I think you missed the referenced [1]:
[1] Yes, we will still
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
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
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
Am 04.09.2011 06:35, schrieb Stas Malyshev:
The ones I'm most worried about are:
1. mysqli_stmt_num_rows() is expected to return number of rows after all
rows were fetched while returning 0 before that. libmysql definitely
Yes, here the test assumes a marginally different behavior. The test
Am 05.09.2011 11:37, schrieb Stas Malyshev:
Hi!
On 9/5/11 2:29 AM, Ulf Wendel wrote:
- BC breakage is impossible because behavior is undefined
- update test, issue gone
OK, since you say it's not the intended behavior to be relied upon, I'll
remove this check from the test (if nobody beats
Am 05.09.2011 12:00, schrieb Stas Malyshev:
Hi!
On 9/5/11 2:49 AM, Ulf Wendel wrote:
Returning a relevant value for stmt_num_rows() seems a valid feature
request that makes perfectly sense to me and is somewhat in line with
the vague non-PS documentation of the case.
It's not a good
No mysqlnd-libmysql BC break here.
Metadata and libmysql - there's hardly a better example why mysqlnd
should be set as a default. With libmysql as a default, PHP 5.4 will
have a randomly crashing default configuration.
https://bugs.php.net/bug.php?id=55001
Am 05.09.2011 15:28, schrieb Andrey Hristov:
On 09/05/2011 03:19 PM, Ulf Wendel wrote:
... always use the latest and greatest. Libmysql bug, exact version
range is not known to me. Feel free to change the test to be skipped
during SKIPIF, for example, like this:
require(connect.inc
Libmysql only test, skipped if using mysqlnd.
No mysqlnd-libmysql BC break here.
Am 02.09.2011 19:19, schrieb Stas Malyshev:
new mysqli() [ext/mysqli/tests/mysqli_connect_oo_warnings.phpt]
This one just times out trying to look up the invalid DNS name. This is
a recent breakage, didn't happen
This is the one and only mysqlnd-libmysql difference of some practical
relevance. I consider it at least questionable if libmysql is correct.
If it was to be decided that mysqlnd is wrong, it is probably like five
lines of code in mysqlnd to change, if need be.
Am 02.09.2011 19:19, schrieb
Am 05.09.2011 18:49, schrieb Rasmus Lerdorf:
In cases where there is no agreement whether something is a bug or just
undefined behaviour it would be really nice if the library authors could
work this out and agree on a common behaviour and failing that PHP
should try to mask the internal
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
Hi,
annoyed by run-tests.php ignoring borked SKIPIF sections, I hacked it to
bail out at me if something seemed suspicious. Maintainers may want to
have a look at:
Fatal/Parse error @ SKIPIF = SKIPIF non functional
BORK 883/9126 [Zend/tests/bug31683.phpt]
BORK 4037/9248
Hi Pierre, hi all,
those three should be left:
BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt]
BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt]
BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt]
They might take more than 1 second (verbally) to fix.
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
Am 16.01.2012 11:19, schrieb Remi Collet:
P.S. well, don't know if having such a hardcoded path is a good idea...
mysqlnd is a libmysql drop-in replacement. Guess what libmysql does... -
do strings libmysqlclient.so | grep mysql.sock on a standard source build.
Ulf
--
PHP Internals - PHP
Am 19.01.2012 13:50, schrieb Johannes Schlüter:
On Fri, 2011-11-18 at 16:06 -0500, Daniel Convissor wrote:
The length property is what's tripping up my unit tests. I'm building
PHP 5.4 from svn for both tests. The only difference between them is
the with-mysqli declaration. Here is a table
Am 19.01.2012 20:27, schrieb Daniel Convissor:
Gentlemen:
On Thu, Jan 19, 2012 at 02:09:12PM +0100, Ulf Wendel wrote:
Am 19.01.2012 13:50, schrieb Johannes Schlüter:
Your server seems to be configured for UTF-8 by default. In my tests the
behavior for both libraries (myslqnd libmsql
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
Am 15.06.2012 03:01, schrieb Anthony Ferrara:
I raised this topic on list over a year ago (
http://marc.info/?l=php-internalsm=130417646507744w=2 ). It was
determined that it wasn't time yet to disable prepared statement
emulation for MySQL yet. However, Rasmus did mention that it was a
Am 15.06.2012 18:36, schrieb Anthony Ferrara:
Chris,
Does this need to be an RFC (should I draft one)? Or can it just be
pulled as-is?
It needs an RFC because it needs to document whether or not the other
DB drivers should also be changed.
It's a PDO driver-specific change. So to me it's
Am 15.06.2012 19:31, schrieb Anthony Ferrara:
Ulf,
It needs an RFC because it needs to document whether or not the other
DB drivers should also be changed.
It's a PDO driver-specific change. So to me it's fairly straight
forward to see that no other drivers need changing... It doesn't even
No worries, Anthony!
Am 15.06.2012 21:15, schrieb Anthony Ferrara:
I would commit, but I do not have commit access (no karma at all). I'm
going away for a few days, but when I get back I will send a separate
request to the list for karma.
I see. It is not up to me to grant karma. I am not
Am 15.06.2012 18:28, schrieb Christopher Jones:
On 06/15/2012 08:34 AM, Ulf Wendel wrote:
As long as client-side escaping is done properly, there is no
practical difference between the [client vs server -prepare]
approaches.
The big problem with this line of reasoning is that the client must
Am 20.06.2012 08:39, schrieb Pierre Joye:
hi Chris,
On Tue, Jun 19, 2012 at 11:45 PM, Christopher Jones
christopher.jo...@oracle.com wrote:
We should take this offline - I can see cases where I'd strongly disagree.
I see no reason to move a discussion offline or off list, this is a
topic
Jani Taskinen schrieb:
Having tests in multiple branches is PITA. Hasn't anyone considered that
the best way would be to move all tests into their own repository
(directory..whatever :) in SVN..? Considering they are supposed to be
used for testing against regressions and BC breaks, they
Jani Taskinen schrieb:
What you risk is that not each and every test is prepared for being run
with every version - although, maybe, in theory it should be. This is
It should not be theory for regression tests? If new release does not
pass the old tests but the old versions still do, then
Johannes Schlüter schrieb:
As I said before in this thread: Realistically we can't drop it. Too
many tutorials, books, applications, ... mention mysql_* and ignore the
limitations and issues the old mysql extension provides...
True, true...
One of the best things one can do is to bash very
Johannes Schlüter schrieb:
On Sat, 2010-06-19 at 12:45 +0200, Sebastian Bergmann wrote:
Am 19.06.2010 11:33, schrieb Patrick ALLAERT:
What are the possible actions/alternatives?
I think this was already mentioned: add a BC layer to ext/mysqli so
that the new extension supports the old
Hi,
I'm wondering if it's a bug to give automatically called destructors
access to constants (PHP Version 5.0.0b1). I'd expect to be neither able
to access global variables nor constants after script termination (die()).
Ulf
$dtor = 'global $dtor variable is visible';
define('DTOR', 'DTOR
Sebastian Bergmann wrote:
Derick Rethans wrote:
-[6] Method names follow the 'studlyCaps'
This is insane.
It's not. Using underscores for all native PHP functions seperates them
nicely from PHP based code, eg. PEAR code.
php_native_func()
myFunc()
or even:
obj-php_native_func()
Pierre-Alain Joye wrote:
On Wed, 03 Dec 2003 11:52:35 +0100
Ulf Wendel [EMAIL PROTECTED] wrote:
obj-php_native_func()
obj-myFunc()
Quick thought, does that work with overload? See Lukas post.
I'm not sure if I understand this. Is there any warranty that overloaded
stuff will always follow
Pierre-Alain Joye wrote:
On Wed, 03 Dec 2003 14:02:00 +0100
Ulf Wendel [EMAIL PROTECTED] wrote:
Most PHP extension have a functional interface. If some extension will
become an OO API in the future this API should not differ from the
functional API. I don't see a good reason why I we should
Derick Rethans wrote:
haha, with these suckyCaps we have two different styles for core-php
functions; that's worse and that's what we *should* care about.
+1
And we gain a simple rule of thumb with underscores:
underscores = build-in functionality = referr to php.net/function_name
study = user
Am 11.09.2013 14:46, schrieb Johannes Schlüter:
On Wed, 2013-09-11 at 13:59 +0300, Arvids Godjuks wrote:
So, I think, it's time to move to a forum.
I hope this is a joke.
+1. A forum is a no go for me.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Am 17.10.2014 um 11:51 schrieb Lester Caine:
On 16/10/14 18:59, christopher jones wrote:
Ulf stated early on in this thread re MySQL
- statement and parameter are send to the server independently
- the server builds the final statement string
Is this ACTUALLY how it works? Since other
Am 17.10.2014 um 13:47 schrieb Lester Caine:
users know what they are getting and where the real security holes are.
Hmm, maybe, you could make this world a better one by contributing to
improve http://php.net/manual/en/pdo.prepared-statements.php ?
For the rest: the MySQL manual and the MySQL
Am 17.10.2014 um 15:09 schrieb Lester Caine:
On 17/10/14 13:20, Ulf Wendel wrote:
users know what they are getting and where the real security holes are.
Hmm, maybe, you could make this world a better one by contributing to
improve http://php.net/manual/en/pdo.prepared-statements.php ?
PDO
82 matches
Mail list logo
