Hi everyone,
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, hence the RFC.
I won't rehash the background overly (there's some more detail in the
RFC), other than to note that we've now had deprecation notices on all
mysql_* functions in the manual for about six months and that the
logical next step is to start generating E_DEPRECATED notices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines. It's my belief that doing so will
hasten the move of users to the more modern (and supported) APIs
available: mysqli and PDO, and that this process will also likely
encourage some users to switch to safer patterns such as prepared
queries at the same time.
I must apologise for the lateness of this RFC: I had hoped to do this
some time before alpha 1, but travel and illness have taken their
toll. Better late than never!
So, please provide comments, feedback, concerns, and so on. Obviously,
this isn't going to a vote for at least a couple of weeks, but earlier
feedback is better.
Thanks,
Adam
Hi everyone,
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, hence the RFC.I won't rehash the background overly (there's some more detail in the
RFC), other than to note that we've now had deprecation notices on all
mysql_* functions in the manual for about six months and that the
logical next step is to start generatingE_DEPRECATEDnotices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines.
While I fully understand the reasons behind this, I still believe this kind of thing should be done using the documentation only.
Generating 'educational' notices will just annoy the end users and in 99% cases they can't do a thing about it -
nobody's going to rewrite a large piece of legacy software just to make PHP happy.
More notices doesn't necessarily mean less people are going to use ext/mysql,
you can't hasten users to move if they don't really want to do it themselves.
--
Wbr,
Antony Dovgal
http://pinba.org - realtime profiling for PHP
Hi everyone,
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, hence the RFC.I won't rehash the background overly (there's some more detail in the
RFC), other than to note that we've now had deprecation notices on all
mysql_* functions in the manual for about six months and that the
logical next step is to start generatingE_DEPRECATEDnotices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines.While I fully understand the reasons behind this, I still believe this kind
of thing should be done using the documentation only.Generating 'educational' notices will just annoy the end users and in 99%
cases they can't do a thing about it -
nobody's going to rewrite a large piece of legacy software just to make PHP
happy.More notices doesn't necessarily mean less people are going to use
ext/mysql,
you can't hasten users to move if they don't really want to do it
themselves.
Well, I think we can communicate, then educate people so that they
dont use ext/mysql any more.
It will take the time needed, but if we want this move to come up, we
need to start it. Doing nothing about it, things wont move.
I like educating through the documentation / through conferences, then
through the code, using the designed-for-that E_DEPRECATED , then
removing the extension.
It may take years, but such a project should be clear to everybody
(RFC), accepted, and started :)
Julien.Pauli
Well, I think we can communicate, then educate people so that they
dont use ext/mysql any more.
It will take the time needed, but if we want this move to come up, we
need to start it. Doing nothing about it, things wont move.I like educating through the documentation / through conferences, then
through the code, using the designed-for-thatE_DEPRECATED, then
removing the extension.
It may take years, but such a project should be clear to everybody
(RFC), accepted, and started :)
I agree, but I feel as though we started this process last year.
(Informally, really, we'd been doing it for a while before that.)
It may or may not be too early to attach E_DEPRECATED to
mysql_connect() — that's why I'm asking. Obviously, I think it's a
reasonable time, personally, but fortunately for everyone, I'm not the
arbiter of what goes into PHP.
Adam, who promises not to reply to any other e-mails until tomorrow.
Mostly because it's nearing on bedtime.
While I fully understand the reasons behind this, I still believe this kind
of thing should be done using the documentation only.Generating 'educational' notices will just annoy the end users and in 99%
cases they can't do a thing about it -
nobody's going to rewrite a large piece of legacy software just to make PHP
happy.More notices doesn't necessarily mean less people are going to use
ext/mysql,
you can't hasten users to move if they don't really want to do it
themselves.
I don't think the documentation is necessarily effective here,
particularly with functions that users tend to know by heart: to pick
on session_register() and friends as an example, it seemed like the
E_DEPRECATED notice added in 5.3.0 was the impetus for quite a few
people to come out of the woodwork on IRC and start asking about
$_SESSION, even though it had been listed as deprecated in the manual
for at least 12 months before that.
I'm not really convinced the average user ever looks at the manual for
things they know, truth be told.
Adam
<skip> > I'm not really convinced the average user ever looks at the manual for > things they know, truth be told.I don't think the documentation is necessarily effective here,
particularly with functions that users tend to know by heart
Well, I'd expect people actively developing applications in PHP to use the docs from time to time.
But my concern is for people using legacy apps.
True, they might not use the docs at all and the only warning they'll get when they do
their usual PHP upgrade is error logs stuffed full of E_DEPRECATED.
So what is they going to do in that case? Disable the notice, of course.
Just a random thought: is it possible to 'emulate' ext/mysql funcs using, say, ext/mysqli,
similar to how ext/mhash functions are now emulated by ext/hash?
--
Wbr,
Antony Dovgal
http://pinba.org - realtime profiling for PHP
Am 12.11.2012 15:48, schrieb Antony Dovgal:
<skip> > I'm not really convinced the average user ever looks at the manual for > things they know, truth be told.I don't think the documentation is necessarily effective here,
particularly with functions that users tend to know by heartWell, I'd expect people actively developing applications in PHP to use
the docs from time to time.
But my concern is for people using legacy apps.
True, they might not use the docs at all and the only warning they'll
get when they do
their usual PHP upgrade is error logs stuffed full of E_DEPRECATED.
So what is they going to do in that case? Disable the notice, of course.
Don't bother. There is a standard way of deprecation, at least I assume
there is. Its proven. Use it: docs warnings, E_DEPRECATED, remove.
Ulf
Am 12.11.2012 15:48, schrieb Antony Dovgal:
<skip>I don't think the documentation is necessarily effective here,
particularly with functions that users tend to know by heartI'm not really convinced the average user ever looks at the manual for
things they know, truth be told.Well, I'd expect people actively developing applications in PHP to use
the docs from time to time.
But my concern is for people using legacy apps.
True, they might not use the docs at all and the only warning they'll
get when they do
their usual PHP upgrade is error logs stuffed full of E_DEPRECATED.
So what is they going to do in that case? Disable the notice, of course.Don't bother. There is a standard way of deprecation, at least I assume
there is. Its proven. Use it: docs warnings, E_DEPRECATED, remove.Ulf
Hi,
I agree to deprecate/remove on the long run, but I think that we should
wait for the next version for doing so.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi
2012/11/12 Ferenc Kovacs tyra3l@gmail.com
I agree to deprecate/remove on the long run, but I think that we should
wait for the next version for doing so.
Wait for the next version? Sorry but thats years away, and where does
that put us? No where in all honestly, if we don't do something
actively against this problem, which indeed is a problem for us and
especially the MySQL guys that a literally "forced" to support it.
TL;DR, if we don't do it now, we just keep postponing it and nothing
will happen.
+1 on the RFC
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Don't bother. There is a standard way of deprecation, at least I assume
there is. Its proven. Use it: docs warnings, E_DEPRECATED, remove.I agree to deprecate/remove on the long run, but I think that we should
wait for the next version for doing so.
Honestly, if we were going to delay the eventual removal (and I'm not
sure we should), I'd rather have an extra release cycle with
E_DEPRECATED, rather than an extra release cycle with
documentation-only warnings that are more easily ignored — so either
way, I'd still want the notices in 5.5.
Adam
Don't bother. There is a standard way of deprecation, at least I assume
there is. Its proven. Use it: docs warnings, E_DEPRECATED, remove.I agree to deprecate/remove on the long run, but I think that we should
wait for the next version for doing so.Honestly, if we were going to delay the eventual removal (and I'm not
sure we should), I'd rather have an extra release cycle with
E_DEPRECATED, rather than an extra release cycle with
documentation-only warnings that are more easily ignored ? so either
way, I'd still want the notices in 5.5.
Personally I think we should E_DEPRECATE it. We will have enough time
till 5.5 RC1 to decide on the RFC within the regular 2-4 weeks.
+1 from me.
While I fully understand the reasons behind this, I still believe this
kind of thing should be done using the documentation only.
following that argument we can deprecate E_DEPRECATED altogether,
can't we?
-1
--
hartmut
logical next step is to start generating
E_DEPRECATEDnotices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines. It's my belief that doing so will
Short comment: Those will mostly be unseen. Most people use the @
operator to silence errors on these functions, so such deprecation
notices would go unseen.
johannes
On 12 November 2012 21:48, Johannes Schlüter
johannes.schlueter@oracle.com wrote:
logical next step is to start generating
E_DEPRECATEDnotices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines. It's my belief that doing so willShort comment: Those will mostly be unseen. Most people use the @
operator to silence errors on these functions, so such deprecation
notices would go unseen.
There are some users we're never going to reach, short of removing the
functions altogether. It's the same for everything we deprecate or
remove — the screaming about ext/sqlite being removed in 5.4 is still
there, for instance, and will probably only increase as distros roll
out 5.4 packages.
A five second Google Code Search suggests the ratio of suppressed
calls to mysql_connect() to unsuppressed ones is about 2:11*, at least
within its increasingly out of date corpus. Admittedly, many of the
users of the unsuppressed code aren't going to have error reporting
turned on anyway, but I don't think the situation's dire.
All that said, is there a different function we could hook into that
does make more sense?
Adam
- No statistical validity claimed. I'm not Nate Silver, nor do I play him on TV.
logical next step is to start generating
E_DEPRECATEDnotices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines. It's my belief that doing so willShort comment: Those will mostly be unseen. Most people use the @
operator to silence errors on these functions, so such deprecation
notices would go unseen.
Also, that type of users won't upgrade PHP anyway...
cheers,
Derick
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, hence the RFC.
Adam,
I am more than happy someone who is not paid by MySQL took the time to
write an RFC.
I/we have been trying to sing the "stop using ext/mysql"-song since at
least since 2006. We put ext/mysql in a (security) bug fix maintenance
mode only years ago. Too many ignore those attempts to get rid of ext/mysql.
I searched a major search engine for PHP MySQL tutorials a few months
ago. 9 out of the top 10 search results demonstrated how to use
ext/mysql. 90% are of the tutorials are ashaming junk in my eyes. Wake
them up. The year 2013 is just around the corner...
However, because of the documentation situation, we waited and waited.
You initiative seems to show that the deprecation message has finally
reached circles outside MySQL.
Ulf
My standpoint would be not to add E_DEPRECATED notices in 5.5... It's
simply used too much to start loudly complaining about it. Instead, what I
would suggest is the following:
- Officially deprecate it now. Right now, on the docs it says
"discouraged", but I would suggest changing that to officially deprecated. - The next release (5.6 or 6) would add deprecation errors to the code.
- The next release (5.7 or 6 or 6.1, etc) would then remove the extension
entirely.
That way there's a significant roadmap towards deprecation, and people can
migrate their code in tune. Sure, there are people who won't do anything
and will break on that major release, but there's not much we can do about
that anyway...
Just my $0.02...
Hi,
We put ext/mysql in a (security) bug fix maintenance mode only
years ago. Too many ignore those attempts to get rid of ext/mysql.
Maybe it's time to put it into full non-maintenance mode then?
I believe MySQL is one of the on-by-default extensions when you
compile PHP blindly (as I'm sure many do), why not make it require
enabling specifically during build configuration, along with an
end-of-script message that states the extension is no longer
maintained (not even security fixes).
- The next release (5.6 or 6) would add deprecation errors to the code.
I think a major version jump would be a good enough excuse to just
drop it entirely ;)
I'd like to see your list moved up one peg though. If you're going to
official deprecate in the docs, why would you wait until the next
version to add deprecation notices to the code? In my opinion the more
visible we make it now (and sooner we get all of the whining out of
the way) the better it will be for all parties.
So I'd like to see deprecation errors in 5.5, and removal in 5.6 which
is still at least around 18 months away (if we estimate based on the
time between 5.4 and 5.5).
Hi,
We put ext/mysql in a (security) bug fix maintenance mode only
years ago. Too many ignore those attempts to get rid of ext/mysql.Maybe it's time to put it into full non-maintenance mode then?
I believe MySQL is one of the on-by-default extensions when you
compile PHP blindly (as I'm sure many do), why not make it require
enabling specifically during build configuration, along with an
end-of-script message that states the extension is no longer
maintained (not even security fixes).
That is simply not true. If you download PHP and do ./configure && make
install you do not get MySQL support. You have to explicitly specify
that you want it.
What is true is that most people no longer build PHP at all. They just
end up with whatever their provider has installed or with whatever
packages they end up installing when they install the PHP app they want
to use. Both Wordpress and Drupal depends on php-mysql on Ubuntu, for
example.
It would be good if we could get the majority of the major PHP apps to
commit to supporting mysqli along the same timeframe as marking this
deprecated.
-Rasmus
Rasmus Lerdorf wrote:
What is true is that most people no longer build PHP at all. They just
end up with whatever their provider has installed or with whatever
packages they end up installing when they install the PHP app they want
to use. Both Wordpress and Drupal depends on php-mysql on Ubuntu, for
example.It would be good if we could get the majority of the major PHP apps to
commit to supporting mysqli along the same timeframe as marking this
deprecated.
And there is no difference here to getting PHP5.3/4 accepted as the current
version of PHP? People have working systems and if the number of problems
changing are too great then they don't change. Rewriting perfectly functional
mysql code to use mysqli is not a trivial move, just as are the problems of
re-writing PHP5.2 code to work cleanly on 5.4. ISP's are stuck between keeping
customers - who are most likely not even very computer literate - working while
fighting the problems that changes such as removing mysql will cause them.
YES people can simply switch off the checks, but again that misses the whole
problem! Having switched off the checks - you have no idea what is about to blow
up. I know people are getting fed up with my banging on about it - I don't have
any answers - but by removing facilities that perhaps 50% of users rely on CAN
only be done if there is some concerted effort to help those users who have no
means of making the changes themselves? Simply saying 'We told you we were doing
it' is just a kick in the teeth when you have also said 'just hide the errors
and your old code will still work' - isn't it?
This is not about stopping progress, it's about much better education on how
that progress should be used ...
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Rewriting perfectly functional mysql code to use mysqli is not a trivial
move, just as are the problems of re-writing PHP5.2 code to work cleanly
on 5.4. ISP's are stuck between keeping customers - who are most likely
not even very computer literate - working while fighting the problems that
changes such as removing mysql will cause them.
I wonder if there have been any plans or suggestions (while dropping the
old ext/mysql code) to provide some sort of seamless migration/alternatives
(similar way it has been done in case of libmysql and mysqlnd)?
In short - just aliasing the old mysql_* to mysqli_* functions (as most used
like _query, _fetch_row/assoc have just mixed variable order)?
rr
Reinis Rozitis r@roze.lv wrote:
Rewriting perfectly functional mysql code to use mysqli is not a
trivial
move, just as are the problems of re-writing PHP5.2 code to work
cleanly
on 5.4. ISP's are stuck between keeping customers - who are most
likely
not even very computer literate - working while fighting the problems
that
changes such as removing mysql will cause them.I wonder if there have been any plans or suggestions (while dropping
the
old ext/mysql code) to provide some sort of seamless
migration/alternatives
(similar way it has been done in case of libmysql and mysqlnd)?
In short - just aliasing the old mysql_* to mysqli_* functions (as most
used
like _query, _fetch_row/assoc have just mixed variable order)?
Reimplementing ext/mysql inside PHP makes no sense. The result of this would be (almost) the exact same code as we have. (ext/mysql is a exremely small wrapper over libmysql/mysqlnd only special thngs are pconnect, auto connect and reusage of default connection) What one might try to do is changing ext/mysql to not use a resource but an mysqli object, then users might swich module by module, instead of breaking the application completely. But I fear we will introduce many bugs that way as this is a quite huge patch. An alternative approach might be to reimplement mysql_* functions using PHP userland code based on mysqli. Then users can load that lib (php.ini autoprepend_file) for compatibility and bugs can be fixed relatively simple (no C needed, no PHP release needed, ...) but again: writing such a lib is a relatively huge project.
In my opinion we tell users as good as we can that ext/mysql is deprecated for some time, if we really want to get rid of it, we have to add E_DEPRECATED and then remove it.Waiting a year more won't change much, there will always people who hit it.
johannes
There's one important thing that I think you all are missing here. You keep
bringing up that we should just use the normal "deprecation" process. The
problem is that the deprecation process was never designed for a feature
like this.
Look at what was deprecated and removed so far. We deprecated register
globals and magic quotes. The process worked there. But was it because of
the process? Or was it because those features were already dead by that
point. Think of this: when 5.3 shipped (introducing E_DEPRECATED for those
features), how many current versions of open source tools relied on those
features? None.
Now, you could point to call-time-pass-by-reference as well. E_DEPRECATED
was added in 5.3 for it. But most of the projects that used it only used it
in a few minor places. The majority of usages were relatively isolated.
Now, look at ext/mysql. The landscape is completely different. Major
projects still rely on it in their most recent versions. Wordpress's latest
trunk uses ext/mysql. And as was said here, it's not a trivial change to
switch from mysql to mysqli or PDO. ext/mysql is still very heavily relied
upon.
What I would suggest, is not adding E_DEPRECATED for 5.5. Instead,
officially deprecate it in the docs. Then start a PR campaign to get
projects like WP to switch away from it. Get the word out there as much as
possible. Then in 1 to 2 years when 5.6/6 is released, add E_DEPRECATED.
Again, my $0.02...
Anthony
On Tue, Nov 13, 2012 at 10:49 AM, Johannes Schlüter
johannes@schlueters.dewrote:
Reinis Rozitis r@roze.lv wrote:
Rewriting perfectly functional mysql code to use mysqli is not a
trivial
move, just as are the problems of re-writing PHP5.2 code to work
cleanly
on 5.4. ISP's are stuck between keeping customers - who are most
likely
not even very computer literate - working while fighting the problems
that
changes such as removing mysql will cause them.I wonder if there have been any plans or suggestions (while dropping
the
old ext/mysql code) to provide some sort of seamless
migration/alternatives
(similar way it has been done in case of libmysql and mysqlnd)?
In short - just aliasing the old mysql_* to mysqli_* functions (as most
used
like _query, _fetch_row/assoc have just mixed variable order)?Reimplementing ext/mysql inside PHP makes no sense. The result of this
would be (almost) the exact same code as we have. (ext/mysql is a exremely
small wrapper over libmysql/mysqlnd only special thngs are pconnect, auto
connect and reusage of default connection) What one might try to do is
changing ext/mysql to not use a resource but an mysqli object, then users
might swich module by module, instead of breaking the application
completely. But I fear we will introduce many bugs that way as this is a
quite huge patch. An alternative approach might be to reimplement mysql_*
functions using PHP userland code based on mysqli. Then users can load that
lib (php.ini autoprepend_file) for compatibility and bugs can be fixed
relatively simple (no C needed, no PHP release needed, ...) but again:
writing such a lib is a relatively huge project.In my opinion we tell users as good as we can that ext/mysql is deprecated
for some time, if we really want to get rid of it, we have to add
E_DEPRECATEDand then remove it.Waiting a year more won't change much,
there will always people who hit it.johannes
There's one important thing that I think you all are missing here. You keep
bringing up that we should just use the normal "deprecation" process. The
problem is that the deprecation process was never designed for a feature
like this.
Serious question: what was it designed for, then? This (along with
magic quotes, and register globals) was always what I had in the back
of my mind when it was being discussed.
Last time I checked, WordPress's trunk also emulated magic quotes. Old
code is old. With all due respect to the WP developers, they've made a
very deliberate choice to maintain extreme backward compatibility
because their plugin ecosystem demands it. Ultimately, they'll
presumably emulate mysql_* in userland if it's that important to them,
just as they are with magic quotes.
I don't think we should let that stop us from removing dead code, or
replacing APIs that promote antipatterns.
What I would suggest, is not adding
E_DEPRECATEDfor 5.5. Instead,
officially deprecate it in the docs. Then start a PR campaign to get
projects like WP to switch away from it. Get the word out there as much as
possible. Then in 1 to 2 years when 5.6/6 is released, add E_DEPRECATED.
It's already deprecated in the documentation, really — I doubt adding
the actual word "deprecated" will make a difference.
If we're going to drag this out, I'd rather spend an extra year with
PHP actually generating warnings, as I said upthread.
Adam
There's one important thing that I think you all are missing here. You keep
bringing up that we should just use the normal "deprecation" process. The
problem is that the deprecation process was never designed for a feature
like this.Serious question: what was it designed for, then? This (along with
<snip> > Now, look at ext/mysql. The landscape is completely different. Major > projects still rely on it in their most recent versions. Wordpress's latest > trunk uses ext/mysql. And as was said here, it's not a trivial change to > switch from mysql to mysqli or PDO. ext/mysql is still very heavily relied > upon.
magic quotes, and register globals) was always what I had in the back
of my mind when it was being discussed.Last time I checked, WordPress's trunk also emulated magic quotes. Old
code is old. With all due respect to the WP developers, they've made a
very deliberate choice to maintain extreme backward compatibility
because their plugin ecosystem demands it. Ultimately, they'll
presumably emulate mysql_* in userland if it's that important to them,
just as they are with magic quotes.I don't think we should let that stop us from removing dead code, or
replacing APIs that promote antipatterns.What I would suggest, is not adding
E_DEPRECATEDfor 5.5. Instead,
officially deprecate it in the docs. Then start a PR campaign to get
projects like WP to switch away from it. Get the word out there as much as
possible. Then in 1 to 2 years when 5.6/6 is released, add E_DEPRECATED.It's already deprecated in the documentation, really — I doubt adding
the actual word "deprecated" will make a difference.If we're going to drag this out, I'd rather spend an extra year with
PHP actually generating warnings, as I said upthread.
I'm with you 100% on this. Wasting yet another few years on telling people...
"hey, soon we will actually begin to discussing, thinking, of taking
action about maybe deprecating the functions officially in an official
manner by which we mean actually throwing the warnings this time, but
for real now not just in the documentation... Seriously, we're not
joking this time..."
Please, this has been dragged out long enough. Give them the warning,
let the next few years push those with dependency issues into forcing
support on their upstreams.
Software must be tolerant of failure and capable of reiteration if it
is to strive. I truly think this "should we or should we throw
E_DEPRECATED" back-and-forth business is rather silly. It's not like
E_DEPRECATED is going to cause every PHP code base on earth to
suddenly and spontaneously combust over night. We are talking about a
version of PHP that will probably take half of these projects the next
3 years to upgrade to (in terms of the majority of their user bases).
By then they're not even using a version of PHP where the extension
has been removed yet. Come on, I mean the wordpress guys are showing
statistics that a 3rd of their entire user base is still using PHP 5.2
for crying out loud. Let's not over-dramatize this thing.
Adam
<snip>There's one important thing that I think you all are missing here. You keep
bringing up that we should just use the normal "deprecation" process. The
problem is that the deprecation process was never designed for a feature
like this.
Serious question: what was it designed for, then? This (along with
magic quotes, and register globals) was always what I had in the back
of my mind when it was being discussed.
There are two big differences here.
The first is that ext/mysql is still very widely used.
Secondly, the deprecation process (throwing deprecation warnings, then
removal) should not be applied to extensions anyway. Magic quotes and
register globals were PHP engine features. There was no other "user
friendly" way to get rid of them, because once gone, it's gone. (Ok,
they could have maybe been made into an extension, but nobody wanted
that anyway...).
The deprecation process here should similar to the process used for
other extensions that have been retired/removed from core (Crack, mhash,
sybase, ming, msql, fdf, fbsql, dbase, filePro, Hyperwave, etc)
- Add "remove from core" status in documentation with notice about
maintenance dropping after 5.next - Remove it from core (those who still need it can pull from PECL)
- If the community needs it after 5.next, then they'll have to step up
and maintain it themselves.
The point is, an extension should never be throwing deprecation warnings
for a planned migration to PECL.
Cheers,
David
The point is, an extension should never be throwing deprecation warnings
for a planned migration to PECL.
We should warn, when we can. There is a reason that we have PHP_DEP_FE in the source as a feature to mark functions deprecated. (99% of all functions are in extensions)
johannes
Hey:
sorry for top reply.
but how about, move mysql to PECL instead of a E_DEPRECATED?
thanks
On Fri, Nov 16, 2012 at 2:30 PM, Johannes Schlüter
johannes@schlueters.de wrote:
The point is, an extension should never be throwing deprecation warnings
for a planned migration to PECL.We should warn, when we can. There is a reason that we have PHP_DEP_FE in the source as a feature to mark functions deprecated. (99% of all functions are in extensions)
johannes
--
Laruence Xinchen Hui
http://www.laruence.com/
Hey:
sorry for top reply.but how about, move mysql to PECL instead of a E_DEPRECATED?
Once ext/mysql is dropped from php-src we will add it to PECL and make a
release there. Still it will be gone for many users.
johannes
2012/11/13 Anthony Ferrara ircmaxell@gmail.com
There's one important thing that I think you all are missing here. You keep
bringing up that we should just use the normal "deprecation" process. The
problem is that the deprecation process was never designed for a feature
like this.Look at what was deprecated and removed so far. We deprecated register
globals and magic quotes. The process worked there. But was it because of
the process? Or was it because those features were already dead by that
point. Think of this: when 5.3 shipped (introducingE_DEPRECATEDfor those
features), how many current versions of open source tools relied on those
features? None.Now, you could point to call-time-pass-by-reference as well.
E_DEPRECATED
was added in 5.3 for it. But most of the projects that used it only used it
in a few minor places. The majority of usages were relatively isolated.Now, look at ext/mysql. The landscape is completely different. Major
projects still rely on it in their most recent versions. Wordpress's latest
trunk uses ext/mysql. And as was said here, it's not a trivial change to
switch from mysql to mysqli or PDO. ext/mysql is still very heavily relied
upon.What I would suggest, is not adding
E_DEPRECATEDfor 5.5. Instead,
officially deprecate it in the docs. Then start a PR campaign to get
projects like WP to switch away from it. Get the word out there as much as
possible. Then in 1 to 2 years when 5.6/6 is released, add E_DEPRECATED.Again, my $0.02...
Anthony
It took me like 10 minutes of "Search & Replace" in my IDE to make a switch
to mysqli and a few more hours to validate that everything is ok and catch
places where search & replace failed. The amount of work is overestimated,
especially if you have a regexp capable search & replace.
Not being able to migrate to mysqli in a few days is a sign of project
messed up so badly, that just upgrading your PHP should break it every
time, and you are probably better off rewriting the whole thing. Or just
freeze the PHP version you are using and let it live until you are able to
rewrite it.
Unfortunately people need a kick in the nuts to start to act. And that old
project argument is exactly from the people that need that kick in the
first place.
I don't even wana start about using a VPS/virtualization and compiling the
damn thing --with-mysql and being happy that you don't have to do anything
to keep it running.
On Tue, Nov 13, 2012 at 8:28 AM, Arvids Godjuks
arvids.godjuks@gmail.com wrote:
It took me like 10 minutes of "Search & Replace" in my IDE to make a switch
to mysqli and a few more hours to validate that everything is ok and catch
places where search & replace failed. The amount of work is overestimated,
especially if you have a regexp capable search & replace.
10 minutes x 50 billion
(http://www.statisticbrain.com/total-number-of-pages-indexed-by-google/
) is not a trivial number. Heck, assume even only 10% of the web pages
on the internet use mysql_* calls, and you're still talking 50 billion
minutes, or about 95 thousand years. At 1%, it's only 9 thousand
years, possibly greater than the entire written and recorded history
of the human race.
Considering there are a huge quantity of PHP end users (Drupal,
Joomla, Wordpress, Magento, etc.) who don't even know what 'regexp'
means, and would take a lot more time than ten minutes just trying to
understand why "my website is broken, can you fix it?".... yeah.
On the less pessimistic side, since I work as a PHP site
author/maintainer for a living, a pool of 9,000 years of work would
suit me just fine. Even 900 years would equate to a huge jobs program
for my field.
-Ronabop
hi,
On Tue, Nov 13, 2012 at 8:28 AM, Arvids Godjuks
arvids.godjuks@gmail.com wrote:It took me like 10 minutes of "Search & Replace" in my IDE to make a switch
to mysqli and a few more hours to validate that everything is ok and catch
places where search & replace failed. The amount of work is overestimated,
especially if you have a regexp capable search & replace.10 minutes x 50 billion
(http://www.statisticbrain.com/total-number-of-pages-indexed-by-google/
) is not a trivial number. Heck, assume even only 10% of the web pages
on the internet use mysql_* calls, and you're still talking 50 billion
minutes, or about 95 thousand years. At 1%, it's only 9 thousand
years, possibly greater than the entire written and recorded history
of the human race.Considering there are a huge quantity of PHP end users (Drupal,
Joomla, Wordpress, Magento, etc.) who don't even know what 'regexp'
means, and would take a lot more time than ten minutes just trying to
understand why "my website is broken, can you fix it?".... yeah.On the less pessimistic side, since I work as a PHP site
author/maintainer for a living, a pool of 9,000 years of work would
suit me just fine. Even 900 years would equate to a huge jobs program
for my field.
Can we stop about arguing about the removal? It is not happening and
won't until 6+. We are talking about adding a E_DEPECRATED notice,
nothing else.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
It took me like 10 minutes of "Search & Replace" in my IDE to make a switch to mysqli and a few more hours to validate that everything is ok and catch places where search & replace failed. The amount of work is overestimated, especially if you have a regexp capable search & replace.
That's not enough in many cases: A key property of ext/MySQL is that you have this "default connection" so users don't have to pass a connection handle. Adding that in a sane way can quickly become non-trivial.
A help there exists, though: Chris posted the link to the oracle wiki which has a link to some script we in the MySQL company wrote (actually that was done before I joined) which tries to convert ext/mysql based applications to mysqli whole trying to catch more edge cases.
Not being able to migrate to mysqli in a few days is a sign of project messed up so badly, that just upgrading your PHP should break it every time, and you are probably better off rewriting the whole thing. Or just freeze the PHP version you are using and let it live until you are able to rewrite it.
Actually PHP has a quite good BC story. Yes, sometimes we break thing (on purpose or accident) but in 90% of the cases easy workaround a exist (I.e. emulating register_globals is quite easy). So users can migrate their "crappy" code from version to version and be happy. Swapping out database access in a mixture of PHP, HTML and SQL is way harder.
Unfortunately people need a kick in the nuts to start to act. And that old project argument is exactly from the people that need that kick in the first place.
I agree, docs and these things aren't enough. E_DEPRECATED is our tool for this.
I don't even wana start about using a VPS/virtualization and compiling the damn thing --with-mysql and being happy that you don't have to do anything to keep it running.
Well, you still need --with-mysqli (or --with-pdo-mysql) which is even more to type ;)
johannes
Johannes Schlüter, MySQL Connectors Team, ORACLE Corporation
What I would suggest, is not adding
E_DEPRECATEDfor 5.5. Instead,
officially deprecate it in the docs. Then start a PR campaign to get
projects like WP to switch away from it. Get the word out there as much as
possible. Then in 1 to 2 years when 5.6/6 is released, add E_DEPRECATED.
A very brief interjection from the documentation team's side of the
fence (though I can't speak for everyone). Extensions, functions,
etc. marked as deprecated in the documentation reflect the reality in
the code. If a function is deprecated in php-src, then we document it
as such in the manual. Since ext/mysql is not yet deprecated in the
source, we cannot "officially deprecate it in the docs" with the usual
"this function is deprecated, blah, blah" messages. This is why we
have adopted the "soft-deprecation" boxes in the manual especially for
ext/mysql, to step forward with that PR campaign (which has been going
on for years upon years) until such a time as the extension is
actually marked as deprecated in php-src.
Long story short, the manual reflects the source. Put the deprecation
into a release and we can document the extension as such. Hold back on
the deprecation in the source and we can't stick a paragraph in the
docs saying "this is deprecated", rather we can only continue to say
that its use is "discouraged".
There's one important thing that I think you all are missing here. You keep bringing up that we should just use the normal "deprecation" process. The problem is that the deprecation process was never designed for a feature like this.
I don't agree.
johannes
Hi Anthony:
Wordpress's latest trunk uses ext/mysql.
WordPress uses a "wpdb" object. Switching out the class to a mysqli
based one is pretty simple and a patch exists. I have a feeling it'll
make it into 3.6.
--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
I see several problems with deprecating ext/mysql:
-
The extension is not broken. The problem is the bad usage.
It can be used safely, and good developers have been doing
so for ages, by creating php wrappers.
In magic quotes, the work has been the opposite. The developers
had been detecting the feature in php and disabling it. -
How many hosts/ISPs have mysqli installed?
I don't have actual numbers, but it used to be much less common
than ext/mysql, which means that unless they those customers
won't be able to run the applications forced to migrate to mysqli.
Yes, the customers should complain and get the extension enabled,
but what will happen instead is that they will use outdated version X
of WordPress, since that one works.
So the problem really moves onto the CMS providers, do they support
new php versions and drop customers in shared hosting, do they delay
supporting the new php versions, or do they reimplement mysql_*
in php?
- A "magic porting script" has been mentioned on this thread.
It is not on the docs, so it is really as if it didn't exist for the 99%
of the
population. Moreover, there is even a FAQ stating that there are no
migration
scripts right now:
http://php.net/manual/en/faq.databases.php#faq.databases.mysql.deprecated
It should be linked from every mysql page.
- If you are sure your ext/mysql usage is safe, it is not possible to
disable the warning
for this functions but keep the other E_DEPRECATED.
- I'm quite sure that there will be a number of problems where the
replacements have
issues, but they are unlikely to be fixed if not forced. For instance, I
remember a
php script using mysql that from reading the code, it shouldn't be
working but it
somehow did. Completely unmaintained, of course.
- The extension is not broken. The problem is the bad usage.
It can be used safely, and good developers have been doing
so for ages, by creating php wrappers.
In magic quotes, the work has been the opposite. The developers
had been detecting the feature in php and disabling it.
ext/mysql is hard to maintain code. It is not not getting new features.
Keeping it up to date for working with new versions of libmysql or
mysqlnd versions is work, we probably could spend that time better.
- How many hosts/ISPs have mysqli installed?
I don't have actual numbers, but it used to be much less common
than ext/mysql, which means that unless they those customers
won't be able to run the applications forced to migrate to mysqli.
I have barely seen systems having ext/mysql but not mysqli.
- A "magic porting script" has been mentioned on this thread.
It is not on the docs, so it is really as if it didn't exist for the 99%
of the
population. Moreover, there is even a FAQ stating that there are no
migration
scripts right now:
http://php.net/manual/en/faq.databases.php#faq.databases.mysql.deprecatedIt should be linked from every mysql page.
Providing a patch to docs is relatively easy )(-> edit.php.net)
the mentioned script is a few years old, one should check and test it
before adding it to the docs, though. Maybe you can test it?
- If you are sure your ext/mysql usage is safe, it is not possible to
disable the warning
for this functions but keep the other E_DEPRECATED.
If the EDEPRECATED is thrown during connect only most people won't see
it anyways. As a typical pattern looks like
if (!@mysql_connect(....)) {
log-and_print( mysql_error() );
}
And therefore hiding raw error messages.
- I'm quite sure that there will be a number of problems where the
replacements have
issues, but they are unlikely to be fixed if not forced. For instance, I
remember a php script using mysql that from reading the code, it shouldn't be
working but it somehow did. Completely unmaintained, of course.
You have years till the last PHP version with ext/mysql will be out of
support. Even then it is likely that one could ext/mysql still working
on newer versions of PHP (PHP barely changes core extension APIs so
people can fetch it from pecl or something, if there is a strong enough
demand we might keep aneye on it for awhile on pecl, too)
If there are real concerns about mysqli or people struggling while
migrating they can feel free to talk to us and we can assist.
johannes
Johannes Schlüter, MySQL Connectors Team, ORACLE Corporation
Reinis Rozitis r@roze.lv wrote:
Rewriting perfectly functional mysql code to use mysqli is not a
trivial
move, just as are the problems of re-writing PHP5.2 code to work
cleanly
on 5.4. ISP's are stuck between keeping customers - who are most
likely
not even very computer literate - working while fighting the problems
that
changes such as removing mysql will cause them.I wonder if there have been any plans or suggestions (while dropping
the
old ext/mysql code) to provide some sort of seamless
migration/alternatives
(similar way it has been done in case of libmysql and mysqlnd)?
In short - just aliasing the old mysql_* to mysqli_* functions (as most
used
like _query, _fetch_row/assoc have just mixed variable order)?Reimplementing ext/mysql inside PHP makes no sense. The result of this would be (almost) the exact same code as we have. (ext/mysql is a exremely small wrapper over libmysql/mysqlnd only special thngs are pconnect, auto connect and reusage of default connection) What one might try to do is changing ext/mysql to not use a resource but an mysqli object, then users might swich module by module, instead of breaking the application completely. But I fear we will introduce many bugs that way as this is a quite huge patch. An alternative approach might be to reimplement mysql_* functions using PHP userland code based on mysqli. Then users can load that lib (php.ini autoprepend_file) for compatibility and bugs can be fixed relatively simple (no C needed, no PHP release needed, ...) but again: writing such a lib is a relatively huge project.
In my opinion we tell users as good as we can that ext/mysql is deprecated for some time, if we really want to get rid of it, we have to add
E_DEPRECATEDand then remove it.Waiting a year more won't change much, there will always people who hit it.
+1 on all of that. I was trying to crystallise my thoughts on the way
home, and you've done it for me. Thanks, Johannes. :)
Adam
Hi
That is simply not true. If you download PHP and do ./configure && make
install you do not get MySQL support. You have to explicitly specify
that you want it.
My apologies then. I actually checked a ./configure output, and saw
under Configuring extensions "checking for MySQL support... no"
I assumed it was going to try to enable it if it was available. Lots
of other extensions have the wording "checking whether to enable",
which is why I differentiated it from those.
YES people can simply switch off the checks, but again that misses the whole
problem! Having switched off the checks - you have no idea what is about to
blow up.
If users wish to deliberately ignore (or worse, specifically disable)
informative messages during development, that is their own problem.
When ext/mysql is finally removed, nobody will be able to say they
didn't have enough warning.
The sooner we get this warning out there (i.e. E_DEPRECATED + message
in the documentation starting with 5.5), the sooner wider community
can start adjusting for it. There is no point delaying it as much as
possible. As Sherif said, there has been far too much procrastination
on the subject already.
Lets get E_DEPRECATED in for the first RC so all of the social-focused
php sites can get their rants out early, and get a few users thinking
about the future of their codebases as soon as possible. Maybe even
some of them will decide to contribute back and write some adoption
guides and/or cheat sheets.
Leigh wrote:
Hi
That is simply not true. If you download PHP and do ./configure && make
install you do not get MySQL support. You have to explicitly specify
that you want it.My apologies then. I actually checked a ./configure output, and saw
under Configuring extensions "checking for MySQL support... no"I assumed it was going to try to enable it if it was available. Lots
of other extensions have the wording "checking whether to enable",
which is why I differentiated it from those.YES people can simply switch off the checks, but again that misses the whole
problem! Having switched off the checks - you have no idea what is about to
blow up.If users wish to deliberately ignore (or worse, specifically disable)
informative messages during development, that is their own problem.
When ext/mysql is finally removed, nobody will be able to say they
didn't have enough warning.
Leigh - the point here is that the vast majority of users know nothing about
this! Their ISP has had to switch E_DEPRECATED off for all of their users simply
to keep legacy sites running. 'Not our problem' is the wrong stance with so many
people reliant on PHP's infrastructure.
The sooner we get this warning out there (i.e.
E_DEPRECATED+ message
in the documentation starting with 5.5), the sooner wider community
can start adjusting for it. There is no point delaying it as much as
possible. As Sherif said, there has been far too much procrastination
on the subject already.Lets get
E_DEPRECATEDin for the first RC so all of the social-focused
php sites can get their rants out early, and get a few users thinking
about the future of their codebases as soon as possible. Maybe even
some of them will decide to contribute back and write some adoption
guides and/or cheat sheets.
The problem will remain as to who helps the vast majority of users who are using
sites that simply work for them. The problems making legacy code work with
PHP5.4 are small compared with converting many millions of sites that currently
use MySQL simply because that is all their ISP's provide, and the code running
their site was probably installed from examples that only ever used 'mysql_' ...
It's simply not practical to strip all of these old code examples from the
internet, so it IS important that new examples are activly published by
everybody to swamp what is now very out of date material.
Many of the sites I'm currently porting from a number of ISP's have needed a lot
of work to tidy them up to run on a new set-up, and there was no way their
owners could ever have done that themselves! And I'm moving them to Firebird
anyway so no problem with MySQl code, but I do have a couple of big sites that
ARE running on mysql_ so I will need to address them at some time.
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Lester Caine wrote:
Their ISP has had to switch
E_DEPRECATEDoff for all of their users simply to
keep legacy sites running.
And this made me laugh ... just trying to log into a new ISP system ...
ERROR: PleskFatalException
Unable to connect to database: mysql_connect()
How many ISP's use plesk for their user support?
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Rasmus Lerdorf in php.internals (Mon, 12 Nov 2012 16:29:35 -0800):
What is true is that most people no longer build PHP at all. They just
end up with whatever their provider has installed or with whatever
packages they end up installing when they install the PHP app they want
to use. Both Wordpress and Drupal depends on php-mysql on Ubuntu, for
example.
Many people are now gradually moving from Drupal 6 to Drupal 7. For
Drupal 7 PHP 5.3 is recommended:
http://drupal.org/requirements
That is not by mistake. Many Drupal 7 modules just aren't fully
supporting PHP 5.4 yet. The issues are getting lower, but there still
are enough issues to make me choose for PHP 5.3 om my development and
production servers.
It would be good if we could get the majority of the major PHP apps to
commit to supporting mysqli along the same timeframe as marking this
deprecated.
How would you want to accomplish that? See the PHP 5.3/5.4 story.
PHP 5.3 will be there for many, many years no matter how EOL the PHP
community declares it.
Jan
Jan Ehrhardt wrote:
Many people are now gradually moving from Drupal 6 to Drupal 7. For
Drupal 7 PHP 5.3 is recommended:
http://drupal.org/requirements
(Somewhat off-topic)
Conversely, WordPress is not moving to 5.3+ for a while, we still have a
huge userbase on 5.2 (~66%): http://wordpress.org/about/stats/
--
Ryan McCue
<http://ryanmccue.info/
hi Rasmus,
Hi,
We put ext/mysql in a (security) bug fix maintenance mode only
years ago. Too many ignore those attempts to get rid of ext/mysql.Maybe it's time to put it into full non-maintenance mode then?
I believe MySQL is one of the on-by-default extensions when you
compile PHP blindly (as I'm sure many do), why not make it require
enabling specifically during build configuration, along with an
end-of-script message that states the extension is no longer
maintained (not even security fixes).That is simply not true. If you download PHP and do ./configure && make
install you do not get MySQL support. You have to explicitly specify
that you want it.What is true is that most people no longer build PHP at all. They just
end up with whatever their provider has installed or with whatever
packages they end up installing when they install the PHP app they want
to use. Both Wordpress and Drupal depends on php-mysql on Ubuntu, for
example.It would be good if we could get the majority of the major PHP apps to
commit to supporting mysqli along the same timeframe as marking this
deprecated.
Here is the take of one of the WP core dev:
My take on the RFC: Toss E_DEPRECATED in already. In our case,
developers will see them, be intrigued enough to contribute. and I
gather we'd have it shipped built-in in Q2 2013.
refs from a twitter conversation:
https://twitter.com/nacin/status/268273606386126849
https://twitter.com/nacin/status/268273185307389952
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi Rasmus:
Both Wordpress and Drupal depends on php-mysql on Ubuntu, for
example.It would be good if we could get the majority of the major PHP apps to
commit to supporting mysqli along the same timeframe as marking this
deprecated.
WordPress is moving in that direction:
http://core.trac.wordpress.org/ticket/21663
--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
My standpoint would be not to add
E_DEPRECATEDnotices in 5.5... It's
simply used too much to start loudly complaining about it. Instead, what I
would suggest is the following:
- Officially deprecate it now. Right now, on the docs it says
"discouraged", but I would suggest changing that to officially deprecated.- The next release (5.6 or 6) would add deprecation errors to the code.
- The next release (5.7 or 6 or 6.1, etc) would then remove the extension
entirely.
I have to disagree with these suggestions. Whether you say it's
"official" or not in the documentation rarely seems to discourage
people from using it. As Adam pointed out, the deprecation error moved
people, with aforementioned functions, to take action, and most people
do not pay much attention to the documentation when it comes to
functions they've been using for years. At least that seems to be the
majority response. I believe the E_DEPRECATED warning is over due
here. This has been talked about for years.
The one constant I notice among the PHP community is that they are
incredibly resistant to take action. I can understand that some of
this resistance is justified and not without good reason, but most of
it is just procrastination. Lets not sit on this one until the next
release, because -- if I recall correctly -- that's the same thing
that was said during the last release. It's been over a year since the
Alpha release of PHP 5.4 and nearly 2 years since 5.2 has been EOL.
There's plenty of wiggle room in there for the majority of PHP users
to become content with ext/mysql being deprecated. Because there are
still people on 5.2 despite it being EOL, and plenty that have only
recently made the move to 5.3, which is soon to be EOL. The time it
will take those to move to 5.4 is likely the time it will take for
whatever comes after 5.5 to be stable. Those that are running legacy
code dependent on ext/mysql can choose to not upgrade as always.
That way there's a significant roadmap towards deprecation, and people can
migrate their code in tune. Sure, there are people who won't do anything
and will break on that major release, but there's not much we can do about
that anyway...Just my $0.02...
Giving people more time and more opportunity to continue using an
extension that is no longer maintained is hardly worthwhile.
There's already a good migration document available and plenty of
people are only finding it by chance when the realize ext/mysql was
soft-deprecated. More are likely to find it and begin a swift path to
migration once they start seeing E_DEPRECATED errors.
As for projects that still depend on ext/mysql, like some of the
popular CMS software out there, this will only compound the effect in
that their communities and user bases will urge those projects to step
up support to the new extensions in the future. Remember, It'll likely
be years before most of those user bases start finding PHP 5.5 as a
default with their hosts. This is plenty of time in my opinion.
Postponing this for a few more years makes no sense.
I'm all for throwing E_DEPRECATED in ext/mysql in 5.5 :)
Am 12.11.2012 15:41, schrieb 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, hence the RFC.Adam,
I am more than happy someone who is not paid by MySQL took the time to
write an RFC.I/we have been trying to sing the "stop using ext/mysql"-song since at
least since 2006. We put ext/mysql in a (security) bug fix maintenance
mode only years ago. Too many ignore those attempts to get rid of
ext/mysql.I searched a major search engine for PHP MySQL tutorials a few months
ago. 9 out of the top 10 search results demonstrated how to use
ext/mysql. 90% are of the tutorials are ashaming junk in my eyes. Wake
them up. The year 2013 is just around the corner...However, because of the documentation situation, we waited and waited.
You initiative seems to show that the deprecation message has finally
reached circles outside MySQL.Ulf
I think the best way of getting rid of trash php tutorials is not
catering to their wrong ways.
Run the standard deprecate-remove cycle instead, as you and most of us
prefer.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg /
http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hello all!
Julien this weekend was at the conference in Riga and we talked with him
exactly about this, how it could be handled and stuff.
The bottom line of our discussion was that I expressed the opinion that
things should really start to move as of 5.5 - postponing it will not make
any difference, because people will start to move only when it starts to
generate some warnings and errors. Until then you can educate them as much
as you want - they just ignore it. Everyone who was susceptible to
education is already educated :)
Just my 2 cents.
P.S. Kill the PDO too, this topic was also was discussed heavily.
On Mon, Nov 12, 2012 at 8:57 AM, Arvids Godjuks
arvids.godjuks@gmail.com wrote:
Hello all!
Julien this weekend was at the conference in Riga and we talked with him
exactly about this, how it could be handled and stuff.
The bottom line of our discussion was that I expressed the opinion that
things should really start to move as of 5.5 - postponing it will not make
any difference, because people will start to move only when it starts to
generate some warnings and errors. Until then you can educate them as much
as you want - they just ignore it. Everyone who was susceptible to
education is already educated :)
Agreed.
P.S. Kill the PDO too, this topic was also was discussed heavily.
Strongly disagreed.
On Mon, Nov 12, 2012 at 4:57 PM, Arvids Godjuks
arvids.godjuks@gmail.com wrote:
Hello all!
Julien this weekend was at the conference in Riga and we talked with him
exactly about this, how it could be handled and stuff.
The bottom line of our discussion was that I expressed the opinion that
things should really start to move as of 5.5 - postponing it will not make
any difference, because people will start to move only when it starts to
generate some warnings and errors. Until then you can educate them as much
as you want - they just ignore it. Everyone who was susceptible to
education is already educated :)
Yes, it's crazy we talked about that exactly yesterday, and today
someone posts an RFC about that.
Julien.P
hi!
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, hence the RFC.I won't rehash the background overly (there's some more detail in the
RFC), other than to note that we've now had deprecation notices on all
mysql_* functions in the manual for about six months and that the
logical next step is to start generatingE_DEPRECATEDnotices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines. It's my belief that doing so will
hasten the move of users to the more modern (and supported) APIs
available: mysqli and PDO, and that this process will also likely
encourage some users to switch to safer patterns such as prepared
queries at the same time.I must apologise for the lateness of this RFC: I had hoped to do this
some time before alpha 1, but travel and illness have taken their
toll. Better late than never!So, please provide comments, feedback, concerns, and so on. Obviously,
this isn't going to a vote for at least a couple of weeks, but earlier
feedback is better.
Huge +1.
The same arguments against deprecating it have been used for years
without effects. Time to use a different approach.
Also the mysql team provides a script which wraps the newers APIs into
a ext/mysql api, allowing easy migration by including it.
adding Ulf to the loop too.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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, hence the RFC.I won't rehash the background overly (there's some more detail in the
RFC), other than to note that we've now had deprecation notices on all
mysql_* functions in the manual for about six months and that the
logical next step is to start generatingE_DEPRECATEDnotices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines. It's my belief that doing so will
hasten the move of users to the more modern (and supported) APIs
available: mysqli and PDO, and that this process will also likely
encourage some users to switch to safer patterns such as prepared
queries at the same time.
IMO, there doesn't need to be a discussion on how to deprecate
ext/mysql. We have E_DEPRECATED for that, just like you write in your
RFC. The only question is "do we want
to deprecate it?". On that one: +1
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
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, hence the RFC.I won't rehash the background overly (there's some more detail in the
RFC), other than to note that we've now had deprecation notices on all
mysql_* functions in the manual for about six months and that the
logical next step is to start generatingE_DEPRECATEDnotices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines. It's my belief that doing so will
hasten the move of users to the more modern (and supported) APIs
available: mysqli and PDO, and that this process will also likely
encourage some users to switch to safer patterns such as prepared
queries at the same time.IMO, there doesn't need to be a discussion on how to deprecate
ext/mysql. We haveE_DEPRECATEDfor that, just like you write in your
RFC. The only question is "do we want
to deprecate it?". On that one: +1cheers,
Derick
-1
Why deprecate? Just because you like PDO doesn't mean everyone else
will like it. Just because mysql_query() tends to create security
vulnerabilities in the hands of the uneducated who have the tendency to
string concatenate SQL queries together in an unsafe fashion, doesn't
mean users won't write insecure code with PDO. Users are lazy - binding
each field separately is going to drive some to resort to string
concatenation, which will result in a situation nearly identical to what
you have already. In the hands of someone who knows what they are
doing, ext/mysql is the same as, if not better than, mysqli and PDO.
The documentation on PDO is structured such that it attempts to pick off
SQL injection vulnerabilities up front. That's great and wonderful, but
the mysql_...() docs could easily get the same treatment. You have a
stable library in ext/mysql that's been hammered out over the years.
You're throwing out perfectly good code.
That's my opinion though. I generally agree with PDO because it will
result in fewer vulnerabilities in the hands of most newbie programmers.
I've seen enough bad code against ext/mysql to know that PDO is a good
thing. I'm ultimately willing to rewrite code if you force the issue.
The real problem: "PHP and MySQL go together" is a fundamental thought
that's been around a long time. There are even popular acronyms
dedicated to this thought: LAMP. The reason it has taken so long to do
anything about ext/mysql is because of this one central thought. So the
real question people are asking is, "Do we deprecate and get rid of a
fundamental thought?" If you are going to do this, just get rid of the
functions altogether and don't deprecate. It will be a lot less
painful. People will yell but they will rewrite their code if you want
everyone using PDO. The problem with ext/mysql is a psychological one,
not a technological one. If you want the transition period to be less
painful, write wrapper functions in userland PHP that uses PDO behind
the scenes that have the same names and parameters as the original
ext/mysql functions. Stick them in PEAR and throw deprecation warnings
on the PEAR repo so the user sees them when they install the wrapper.
IMO, very few, if any, extensions should be enabled by default.
Including them by default implies they should be in the core, not some
extension.
--
Thomas Hruska
CubicleSoft President
Barebones CMS is a high-performance, open source content management
system for web developers operating in a team environment.
An open source CubicleSoft initiative.
Your choice of a MIT or LGPL license.
Users are lazy - binding each field separately is going to drive some to
resort to string concatenation, which will result in a situation nearly
identical to what you have already.
You don't have to bind each field separately. I don't think I have
ever done that with PDO . . .
On Wed, Nov 21, 2012 at 7:43 AM, Thomas Hruska thruska@cubiclesoft.comwrote:
I've written an RFC to cover deprecating ext/mysql in PHP 5.5:
https://wiki.php.net/rfc/**mysql_deprecationhttps://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, hence the RFC.I won't rehash the background overly (there's some more detail in the
RFC), other than to note that we've now had deprecation notices on all
mysql_* functions in the manual for about six months and that the
logical next step is to start generatingE_DEPRECATEDnotices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines. It's my belief that doing so will
hasten the move of users to the more modern (and supported) APIs
available: mysqli and PDO, and that this process will also likely
encourage some users to switch to safer patterns such as prepared
queries at the same time.IMO, there doesn't need to be a discussion on how to deprecate
ext/mysql. We haveE_DEPRECATEDfor that, just like you write in your
RFC. The only question is "do we want
to deprecate it?". On that one: +1cheers,
Derick-1
Why deprecate? Just because you like PDO doesn't mean everyone else will
like it. Just because mysql_query() tends to create security
vulnerabilities in the hands of the uneducated who have the tendency to
string concatenate SQL queries together in an unsafe fashion, doesn't mean
users won't write insecure code with PDO. Users are lazy - binding each
field separately is going to drive some to resort to string concatenation,
which will result in a situation nearly identical to what you have already.
In the hands of someone who knows what they are doing, ext/mysql is the
same as, if not better than, mysqli and PDO.
PHP is not etched in stone. It is an ever-evolving, ever-improving
language. I'm not sure I understand the reasoning behind your "ext/mysql
is the same as, if not better than, mysqli and PDO" remark. The ext/mysql
extension does not support prepared statements; mysqli and PDO do. The
ext/mysql extension doesn't support a lot of things that mysqli and PDO do,
in fact. Conversely, I'm not aware of anything that ext/mysql can do that
mysqli and PDO cannot. The only thing it's good for now is if you're
running an ancient MySQL server <4.1; in which case, chances are you're not
going to be running the latest PHP version, anyway.
There is simply no rational reason for continuing to use ext/mysql over
mysqli and PDO. It does present significant security vulnerabilities. It
doesn't take advantage of the latest features and improvements in MySQL.
This isn't about what we "like." This is about what works best and what
doesn't. The ext/mysql extension is simply obsolete. People only keep
using it because they don't know any better. Throwing E_DEPRECATED in 5.5
will help rectify that. If you're upgrading to PHP 6 in the future, you
should already be aware that there will be significant changes present, so
the removal of ext/mysql should not be an issue.
Some things become obsolete with time. It's just a fact of life. If you
can't bring yourself to update your code to remove calls to something that
has arguably been obsolete for the last 5+ years now, then don't upgrade
PHP. If you want everything to stay the same, then stick with whatever
older version you think is perfect. Otherwise, if you choose to upgrade,
you have to understand that some things inevitably have to change in the
name of progress.
--Kris
On Wed, Nov 21, 2012 at 7:43 AM, Thomas Hruska thruska@cubiclesoft.comwrote:
Why deprecate? Just because you like PDO doesn't mean everyone else will
like it. Just because mysql_query() tends to create security
vulnerabilities in the hands of the uneducated who have the tendency to
string concatenate SQL queries together in an unsafe fashion, doesn't mean
users won't write insecure code with PDO. Users are lazy - binding each
field separately is going to drive some to resort to string concatenation,
which will result in a situation nearly identical to what you have already.
In the hands of someone who knows what they are doing, ext/mysql is the
same as, if not better than, mysqli and PDO.
PHP is not etched in stone. It is an ever-evolving, ever-improving
language. I'm not sure I understand the reasoning behind your "ext/mysql
is the same as, if not better than, mysqli and PDO" remark.
"In the hands of someone who knows what they are doing, ext/mysql is
the same as, if not better than, mysqli and PDO."
...is the sentence in question. Note the qualifier.
The ext/mysql
extension does not support prepared statements; mysqli and PDO do
If you know what your're doing, prepared statement workflows are just
wasteful code bloat with absolutely no tangible benefits.
Again, note the qualifier.
There is simply no rational reason for continuing to use ext/mysql over
mysqli and PDO.
Not editing millions of lines of stable, and secure, code is a rational reason.
<sarcasm> Well, C has had tons of insecurities over the years, maybe we should migrate PHP to be written in, oh, Ruby or something new and shiny like that, because newer languages make shooting yourself in the foot harder, and "new" somehow means "secure". </sarcasm>It does present significant security vulnerabilities.
If there are actual security vulnerabilities in ext/mysql, by all
means, that's a good reason for rapid deprecation, but if there are
security vulnerabilities because people who didn't know what they
were doing.created them, that's a battle that cannot be won.
-Ronabop
Hi everyone,
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, hence the RFC.I won't rehash the background overly (there's some more detail in the
RFC), other than to note that we've now had deprecation notices on all
mysql_* functions in the manual for about six months and that the
logical next step is to start generatingE_DEPRECATEDnotices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines. It's my belief that doing so will
hasten the move of users to the more modern (and supported) APIs
available: mysqli and PDO, and that this process will also likely
encourage some users to switch to safer patterns such as prepared
queries at the same time.I must apologise for the lateness of this RFC: I had hoped to do this
some time before alpha 1, but travel and illness have taken their
toll. Better late than never!So, please provide comments, feedback, concerns, and so on. Obviously,
this isn't going to a vote for at least a couple of weeks, but earlier
feedback is better.Thanks,
Adam
I'm +1 on using E_DEPRECATED. Anything beyond that would be -1 since
it is likely to break BC (I note that the Release Process RFC doesn't
defines "compatibility", but I think we are have a gut feel for what
it means)
Adam, can you:
-
Add this link to the RFC?:
https://wikis.oracle.com/display/mysql/Converting+to+MySQLi -
Mention how to turn off
E_DEPRECATEDwarnings in the RFC?
When users of 5.5 stumble on the new messages, we can then simply
point them to the RFC.
Chris
On 13 November 2012 08:44, Christopher Jones
christopher.jones@oracle.com wrote:
Adam, can you:
Add this link to the RFC?:
https://wikis.oracle.com/display/mysql/Converting+to+MySQLiMention how to turn off
E_DEPRECATEDwarnings in the RFC?When users of 5.5 stumble on the new messages, we can then simply
point them to the RFC.
Done and done. I've added a (short) workarounds section towards the
bottom, which can be moved up later if the RFC is accepted.
Against that, I'm not a big fan of RFCs as documentation, but that's a
separate discussion. :)
Adam
On 13 November 2012 08:44, Christopher Jones
christopher.jones@oracle.com wrote:Adam, can you:
Add this link to the RFC?:
https://wikis.oracle.com/display/mysql/Converting+to+MySQLiMention how to turn off
E_DEPRECATEDwarnings in the RFC?When users of 5.5 stumble on the new messages, we can then simply
point them to the RFC.Done and done. I've added a (short) workarounds section towards the
bottom, which can be moved up later if the RFC is accepted.Against that, I'm not a big fan of RFCs as documentation, but that's a
separate discussion. :)
Content like this deserves to be in RFCs so voters can quickly judge the impact of proposed changes on end users.
Thanks for adding it,
Chris
Adam
Hi!
- Mention how to turn off
E_DEPRECATEDwarnings in the RFC?Done and done. I've added a (short) workarounds section towards the
bottom, which can be moved up later if the RFC is accepted.
Please note currently PHP has no mechanism of turning off any warnings
or errors. The best you can do is to cause them not be printed. However,
any tool that intercepts error messages still sees them, they still
consume resources when produced, still may break unit tests if you're
not aware of them and they convert errors to failures like PHPUnit does,
still will break any code that sets it's won error reporting if it
doesn't remember to disable deprecated messages, etc. So adding warnings
hurts performance and may hurt functionality even if you don't see them.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
- Mention how to turn off
E_DEPRECATEDwarnings in the RFC?Done and done. I've added a (short) workarounds section towards the
bottom, which can be moved up later if the RFC is accepted.Please note currently PHP has no mechanism of turning off any warnings
or errors. The best you can do is to cause them not be printed. However,
any tool that intercepts error messages still sees them, they still
consume resources when produced, still may break unit tests if you're
not aware of them and they convert errors to failures like PHPUnit does,
still will break any code that sets it's won error reporting if it
doesn't remember to disable deprecated messages, etc. So adding warnings
hurts performance and may hurt functionality even if you don't see them.
If PHPUnit breaks on E_DEPRECATED by default I would consider it broken.
(But I see your point)
johannes
--
Johannes Schlüter, MySQL Connectors Team, ORACLE Corporation
Am 13.11.2012 04:08, schrieb Adam Harvey:
On 13 November 2012 08:44, Christopher Jones
christopher.jones@oracle.com wrote:Adam, can you:
- 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.
Ulf
Ulf Wendel wrote:
- Add this link to the RFC?:
https://wikis.oracle.com/display/mysql/Converting+to+MySQLiAs the author I cannot recommend materials created in 2006 and not
updated since then for inclusion into a RFC.
At the end of the day this is the problem all around. There needs sufficient
volume of mysqli examples and tutorials to at least get some on a search for
'mysql php tutorial'.
This IS all about education carrots rather than irritating sticks. Perhaps there
needs to be a concerted campaign to get the key tutorials such as at
http://www.w3schools.com updated to a much more modern format?
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Am 20.11.2012 11:22, schrieb Lester Caine:
Ulf Wendel wrote:
- Add this link to the RFC?:
https://wikis.oracle.com/display/mysql/Converting+to+MySQLiAs the author I cannot recommend materials created in 2006 and not
updated since then for inclusion into a RFC.At the end of the day this is the problem all around. There needs
sufficient volume of mysqli examples and tutorials to at least get some
on a search for 'mysql php tutorial'.
This is no argument for adding this specific old wiki stuff to the RFC,
is it? However, I reckon your proposal.
Ulf
Ulf Wendel wrote:
Am 20.11.2012 11:22, schrieb Lester Caine:
Ulf Wendel wrote:
- 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 of the day this is the problem all around. There needs
sufficient volume of mysqli examples and tutorials to at least get some
on a search for 'mysql php tutorial'.This is no argument for adding this specific old wiki stuff to the RFC, is it?
However, I reckon your proposal.
In the absence of nothing better?
Ideally someone who knows mysqli inside out needs to update these documents ...
I'll stick to converting mysql users to Firebird :)
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Am 20.11.2012 13:25, schrieb Lester Caine:
Ulf Wendel wrote:
Am 20.11.2012 11:22, schrieb Lester Caine:
Ulf Wendel wrote:
- 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 of the day this is the problem all around. There needs
sufficient volume of mysqli examples and tutorials to at least get some
on a search for 'mysql php tutorial'.This is no argument for adding this specific old wiki stuff to the
RFC, is it?
However, I reckon your proposal.In the absence of nothing better?
Lester, you may want to read the fine manual:
http://www.php.net/manual/en/mysqli.quickstart.php
Ideally someone who knows mysqli inside out needs to update these
documents ... I'll stick to converting mysql users to Firebird :)
Are you aware of what you do to the discussion and the list?
Ulf Wendel wrote:
- Add this link to the RFC?:
https://wikis.oracle.com/display/mysql/Converting+to+MySQLiAs the author I cannot recommend materials created in 2006 and not
updated since then for inclusion into a RFC.At the end of the day this is the problem all around. There needs sufficient
volume of mysqli examples and tutorials to at least get some on a search for
'mysql php tutorial'.This IS all about education carrots rather than irritating sticks. Perhaps
there needs to be a concerted campaign to get the key tutorials such as at
http://www.w3schools.com updated to a much more modern format?--
Lester Caine - G8HFLContact - 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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre Joye wrote:
https://www.google.de/search?q=php+mysqli+tutorial
Which gives About 273,000 results and the first of them are causing more
confusion with PDO alternative.
BUT newcomers know nothing about mysqli and will be looking for
https://www.google.de/search?q=php+mysql+tutorial
gives About 9,040,000
The most important think here is getting the word out and getting as I said -
get the more popular tutorial sites 'converted' or at least pointing out that
mysqlI is now what you have to look for.
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
2012/11/20 Lester Caine lester@lsces.co.uk
Pierre Joye wrote:
https://www.google.de/search?**q=php+mysqli+tutorialhttps://www.google.de/search?q=php+mysqli+tutorial
Which gives About 273,000 results and the first of them are causing more
confusion with PDO alternative.BUT newcomers know nothing about mysqli and will be looking for
https://www.google.de/search?**q=php+mysql+tutorialhttps://www.google.de/search?q=php+mysql+tutorial
gives About 9,040,000
And https://www.google.de/search?q=standart gives you 128,000,000 results.
You cannot avoid, that outdated, or wrong information remains. The bigger
problem seems to be, that the google results are treated with more
attention, then the official manual. Any idea against that?
The most important think here is getting the word out and getting as I
said - get the more popular tutorial sites 'converted' or at least pointing
out that mysqlI is now what you have to look for.
Who should be responsible for this task in your opinion? For example why
didn't you contacted w3schools already?
--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=**contacthttp://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
Rainbow Digital Media - http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk--
Lester,
My point is: less talk, more acts.
You want better docs? Contribute.
Cheers,
Pierre Joye wrote:
Which gives About 273,000 results and the first of them are causing more
confusion with PDO alternative.BUT newcomers know nothing about mysqli and will be looking for
https://www.google.de/search?q=php+mysql+tutorial
gives About 9,040,000The most important think here is getting the word out and getting as I said
- get the more popular tutorial sites 'converted' or at least pointing out
that mysqlI is now what you have to look for.--
Lester Caine - G8HFLContact - 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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Lester,
My point is: less talk, more acts.
You want better docs? Contribute.
Cheers,
I think there's definitely room for improvement in making mysqli tutorials
more common and accessible, but I don't think that should cause us to delay
deprecation. I do like Lester's idea of forming a task force to
aggressively replace mysql tutorials with mysqli. I'd be happy to help out
with that if there's sufficient interest.
--Kris
hi,
Lester,
My point is: less talk, more acts.
You want better docs? Contribute.
Cheers,
I think there's definitely room for improvement in making mysqli tutorials
more common and accessible, but I don't think that should cause us to delay
deprecation. I do like Lester's idea of forming a task force to
aggressively replace mysql tutorials with mysqli. I'd be happy to help out
with that if there's sufficient interest.
A task force? http://edit.php.net and go ahead. No offense meant but
there is a time to argue endlessly (rarely but..) and there is time to
actually do something. I think the latter should be done now.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
On Tue, Nov 20, 2012 at 5:12 AM, Pierre Joye pierre.php@gmail.com
wrote:Lester,
My point is: less talk, more acts.
You want better docs? Contribute.
Cheers,
I think there's definitely room for improvement in making mysqli
tutorials
more common and accessible, but I don't think that should cause us to
delay
deprecation. I do like Lester's idea of forming a task force to
aggressively replace mysql tutorials with mysqli. I'd be happy to help
out
with that if there's sufficient interest.A task force? http://edit.php.net and go ahead. No offense meant but
there is a time to argue endlessly (rarely but..) and there is time to
actually do something. I think the latter should be done now.
I agree with you, but I was referring to reaching out to external
sites/blogs/etc that still have outdated mysql tutorials appearing in
search results. =)
--Kris
Ulf Wendel wrote:
- 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 of the day this is the problem all around. There needs
sufficient volume of mysqli examples and tutorials to at least get
some on a search for 'mysql php tutorial'.This IS all about education carrots rather than irritating sticks.
Perhaps there needs to be a concerted campaign to get the key
tutorials such as at http://www.w3schools.com updated to a much more
modern format?
There was a concerted campaign to get w3schools updated, but as far as I
know, it's fallen on deaf ears. And it's not just their PHP info that's
outdated.
See w3fools.com
Cheers,
David
Ulf Wendel wrote:
- Add this link to the RFC?:
https://wikis.oracle.com/**display/mysql/Converting+to+**MySQLihttps://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 of the day this is the problem all around. There needs
sufficient volume of mysqli examples and tutorials to at least get some on
a search for 'mysql php tutorial'.This IS all about education carrots rather than irritating sticks.
Perhaps there needs to be a concerted campaign to get the key tutorials
such as at http://www.w3schools.com updated to a much more modern format?There was a concerted campaign to get w3schools updated, but as far as I
know, it's fallen on deaf ears. And it's not just their PHP info that's
outdated.See w3fools.com
Cheers,
David
+1 on ignoring w3schools. Those guys are idiots.
I'd never seen the w3fools site before and I love it! One thing in there
got me thinking: One of their suggestions to w3schools is that they should
"wikify" their content. They obviously won't do that, but what if we
launched something like that instead? The PHP manual is a great functional
reference point, but it's understandably thin when it comes to tutorials.
What if some of us got together and launched a new wiki (I'm thinking
something separate from wiki.php.net) site dedicated to providing accurate,
up-to-date tutorials on how to do _____ in PHP? Unlike most other sites,
we'd be in a good position to displace inaccurate sources like w3schools in
the search results.
Just a thought, though I'm sure it's not an original one.
--Kris
What if some of us got together and launched a new wiki (I'm thinking
something separate from wiki.php.net) site dedicated to providing accurate,
up-to-date tutorials on how to do _____ in PHP? Unlike most other sites,
we'd be in a good position to displace inaccurate sources like w3schools in
the search results.Just a thought, though I'm sure it's not an original one.
--Kris
Perhaps, but this is the ext/mysql deprecation discussion. Creating a new
wiki site is outside the scope of this proposal.
Christopher Jones wrote:
Adam, can you:
- Add this link to the RFC?:
https://wikis.oracle.com/display/mysql/Converting+to+MySQLi
Now that IS a good start!
Adding that to core documentation as well could be helpful?
But in a lot of cases it is the pre-loaded 'abstraction layer' that may be the
problem rather than the code for the site.
- Mention how to turn off
E_DEPRECATEDwarnings in the RFC?
But with a strong warning that on a later version of PHP things WILL stop
working altogether? More often nowE_DEPRECATEDis already switched off simply
to get PHP5.2 code to run so no one would see them anyway!
When users of 5.5 stumble on the new messages, we can then simply
point them to the RFC.
I think this is part of the problem. The material from the RFC's should be used
as a source to update the core documentation? Rather than another pile of notes.
IS the wiki intended to be a replacement for the core documentation? I've always
viewed it as a developers notepad for work that is in progress rather than
documentation itself, and once completed that material moves to the core manual?
In the case of removing any extension, good documentation is the key, and making
this more accessible to the 'general public', who in any case will probably
think 'PHP is ditching Mysql' what's going on ...
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Christopher Jones wrote:
When users of 5.5 stumble on the new messages, we can then simply
point them to the RFC.I think this is part of the problem. The material from the RFC's
should be used as a source to update the core documentation? Rather
than another pile of notes.
It's not a problem. We point them to the wiki so they can see the
rationale behind the change. This potentially reduces user
frustration. Our documentation should not have that rationale.
Chris
Hi!
But with a strong warning that on a later version of PHP things WILL stop
working altogether? More often nowE_DEPRECATEDis already switched off simply
Why again we must breaking people's working code?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas Malyshev wrote:
But with a strong warning that on a later version of PHP things WILL stop
working altogether? More often now
E_DEPRECATEDis already switched off simply
Why again we must breaking people's working code?
Something I've been asking for years ;)
Bigger frameworks still designing for PHP5.3 is happening because 5.2 code still
works on 5.3 by hiding warnings, but fails on 5.4. They are trying to keep THEIR
users functional in the real world, and the real world is dragging it's feet
simply because the majority of users would not know what E_DEPRECATED means.
"They have had plenty of time to fix this" assumes that the people who wrote the
original code are still around TO fix it? I'm still finding live code that
originated in PHP4 days - using 'mysql_' - and works perfectly - on 5.2.
I have three options now ...
1/ Stick with a stack that will run their code
2/ Tell the customers they need to repair all their code
3/ Charge them for the time to repair the code for them
Many ISP's are simply opting for 1 because 2 can't happen on many accounts, and
there is not enough time available for 3 which most customers could not afford
anyway.
I've been forced to move sites from their exiting hosting simply because that
host HAS upgraded and I don't have time to fix all the problems on code for the
customer!
FINALLY sorted why everything was broken moving from Apache2.2 to 2.4 now I have
to work out the 'politically correct' fix for that :(
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Why again we must breaking people's working code?
Something I've been asking for years ;)
Bigger frameworks still designing for PHP5.3 is happening because 5.2
code still works on 5.3 by hiding warnings, but fails on 5.4. They are
trying to keep THEIR users functional in the real world, and the real
world is dragging it's feet simply because the majority of users would
not know whatE_DEPRECATEDmeans. "They have had plenty of time to fix
this" assumes that the people who wrote the original code are still
around TO fix it? I'm still finding live code that originated in PHP4
days - using 'mysql_' - and works perfectly - on 5.2.
I have three options now ...
1/ Stick with a stack that will run their code
2/ Tell the customers they need to repair all their code
3/ Charge them for the time to repair the code for them
Coming from a distribution packaging background, keeping software alive
and secure is an ongoing effort. It's not buy and forget.
Scripts and frameworks need security and bug fixes, binary code needs to
be rebuilt against newer base system libraries, and as compiler versions
mature, a lot of code which previously built needs to be fixed even if
it's unchanged. There is nothing wrong with that. It's just the way it
is. Unmaintained Software will retain unfixed bugs, unfixed security
holes and ultimately break because of external changes. the mysql
extension maintainers do not want to or cannot support the extension for
much longer. It's perfectly ok for them to do so. php internals' task is
to run this through their deprecation cycle and educate anybody who is
listening how to cope with it.
--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg /
http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Ralf Lang wrote:
Unmaintained Software will retain unfixed bugs, unfixed security
holes and ultimately break because of external changes. the mysql
extension maintainers do not want to or cannot support the extension for
much longer.
Is there anything drastic that still needs to be fixed in the current version of
the extension? Can't we just start developing a 'legacy' build which will be
available as an fallback and something that others can lightly maintain in terms
of any critical security stuff? The idea of an LTS version has been continually
shot down, but having something that can reliably run legacy code and where
working versions of 'eol' extensions like mysql can be stored, rather than the
vague hit and miss situation currently where we as developers have no idea what
an ISP's setup may be using versions wise? I make no apology for repeating that
this SHOULD have been done before PHP5.3 was pushed out and I would be
interested to see if there IS any interest in reopening PHP5.2 as a legacy
platform, as certainly 5.3/4 do not provide that base! At least it would provide
a reference point to work from.
Crib sheets of information on how to move code from the legacy base to the
current build are then easier to develop while currently if PHP5.2 code has not
been 'updated to' 5.3, then moving it two or now three versions is even more
painful. And we still do not have good references of how code SHOULD be built
nowadays. Certainly my own code bases are apparently archaic but just fixing
E_STRICT warnings does not produce clean PHP5.4 code, just bodged 5.? stuff :(
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
hi Adam,
Hi everyone,
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, hence the RFC.I won't rehash the background overly (there's some more detail in the
RFC), other than to note that we've now had deprecation notices on all
mysql_* functions in the manual for about six months and that the
logical next step is to start generatingE_DEPRECATEDnotices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines. It's my belief that doing so will
hasten the move of users to the more modern (and supported) APIs
available: mysqli and PDO, and that this process will also likely
encourage some users to switch to safer patterns such as prepared
queries at the same time.I must apologise for the lateness of this RFC: I had hoped to do this
some time before alpha 1, but travel and illness have taken their
toll. Better late than never!So, please provide comments, feedback, concerns, and so on. Obviously,
this isn't going to a vote for at least a couple of weeks, but earlier
feedback is better.
I think there is a somehow clear consensus that E_DEPRECATED is just fine.
Discussions now are mostly about killing mysql or some ever ending
rant about notices being a breakage.
I would suggest to move to the vote phase after the one week period.
Thanks for bringing that up,
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
2012/11/12 Adam Harvey aharvey@php.net:
Hi everyone,
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, hence the RFC.I won't rehash the background overly (there's some more detail in the
RFC), other than to note that we've now had deprecation notices on all
mysql_* functions in the manual for about six months and that the
logical next step is to start generatingE_DEPRECATEDnotices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines. It's my belief that doing so will
hasten the move of users to the more modern (and supported) APIs
available: mysqli and PDO, and that this process will also likely
encourage some users to switch to safer patterns such as prepared
queries at the same time.I must apologise for the lateness of this RFC: I had hoped to do this
some time before alpha 1, but travel and illness have taken their
toll. Better late than never!So, please provide comments, feedback, concerns, and so on. Obviously,
this isn't going to a vote for at least a couple of weeks, but earlier
feedback is better.Thanks,
Adam
--
Adam,
Maybe it is worth mentioning in the RFC what the E_DEPRECATED notice
message would look like so that people hiding it know what the plan
is.
e.g.:
"mysql_() functions are, as of PHP 5.5, deprecated and will be
removed in next major release. Use the mysqli_() functions instead".
Patrick
2012/11/12 Adam Harvey aharvey@php.net:
Hi everyone,
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, hence the RFC.I won't rehash the background overly (there's some more detail in the
RFC), other than to note that we've now had deprecation notices on all
mysql_* functions in the manual for about six months and that the
logical next step is to start generatingE_DEPRECATEDnotices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines. It's my belief that doing so will
hasten the move of users to the more modern (and supported) APIs
available: mysqli and PDO, and that this process will also likely
encourage some users to switch to safer patterns such as prepared
queries at the same time.I must apologise for the lateness of this RFC: I had hoped to do this
some time before alpha 1, but travel and illness have taken their
toll. Better late than never!So, please provide comments, feedback, concerns, and so on. Obviously,
this isn't going to a vote for at least a couple of weeks, but earlier
feedback is better.Thanks,
Adam
--
Adam,
Maybe it is worth mentioning in the RFC what the
E_DEPRECATEDnotice
message would look like so that people hiding it know what the plan
is.
e.g.:
"mysql_() functions are, as of PHP 5.5, deprecated and will be
removed in next major release. Use the mysqli_() functions instead".
Good point. I did put some proposed wording in the patch, but I'll add it
to the RFC when I get home tomorrow and am not just on a phone.
Adam
2012/11/12 Adam Harvey aharvey@php.net:
Hi everyone,
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, hence the RFC.I won't rehash the background overly (there's some more detail in the
RFC), other than to note that we've now had deprecation notices on all
mysql_* functions in the manual for about six months and that the
logical next step is to start generatingE_DEPRECATEDnotices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines. It's my belief that doing so will
hasten the move of users to the more modern (and supported) APIs
available: mysqli and PDO, and that this process will also likely
encourage some users to switch to safer patterns such as prepared
queries at the same time.I must apologise for the lateness of this RFC: I had hoped to do this
some time before alpha 1, but travel and illness have taken their
toll. Better late than never!So, please provide comments, feedback, concerns, and so on. Obviously,
this isn't going to a vote for at least a couple of weeks, but earlier
feedback is better.Thanks,
Adam
--
Adam,
Maybe it is worth mentioning in the RFC what the
E_DEPRECATEDnotice
message would look like so that people hiding it know what the plan
is.
e.g.:
"mysql_() functions are, as of PHP 5.5, deprecated and will be
removed in next major release. Use the mysqli_() functions instead".
Good point. I did put some proposed wording in the patch, but I'll add it
to the RFC when I get home tomorrow and am not just on a phone.Adam
Could we not mention mysqli unless you mention PDO as well?
Maybe it is worth mentioning in the RFC what the
E_DEPRECATEDnotice
message would look like so that people hiding it know what the plan
is.
e.g.:
"mysql_() functions are, as of PHP 5.5, deprecated and will be
removed in next major release. Use the mysqli_() functions instead".Good point. I did put some proposed wording in the patch, but I'll add it
to the RFC when I get home tomorrow and am not just on a phone.Could we not mention mysqli unless you mention PDO as well?
I've added the wording I put in the patch to the RFC. For the record, it is:
"The mysql extension is deprecated and will be removed in the future:
use mysqli or PDO instead"
This is basically a cut down version of the longer message in the
manual on each ext/mysql function, except explicitly noting the
deprecation. I'm not at all averse to adding a link to the Choosing an
API manual page to help developers make an informed choice (and,
ideally, we could beef that up to include more detail on what
migration actually looks like) — this does feel like something we
could tune after voting on the bigger issue, though.
My intention at this stage is to call a vote next Monday: it feels
like the discussion has mostly died down now (which isn't to say I
think we're at a consensus necessarily — it just feels as though the
flurry of opinions have been made and argued either way), and I'm
hoping that everyone can have a think about where and how they'd like
to see this move forward (if at all) between now and then. Given we've
only just hit alpha 1, I don't think we need to rush into a decision
right now for the sake of one.
Thanks to everyone so far for their input — I think it's been a
valuable, productive discussion.
Cheers,
Adam, who is still personally in favour of deprecation. :)
Adam,
My intention at this stage is to call a vote next Monday: it feels
like the discussion has mostly died down now (which isn't to say I
think we're at a consensus necessarily — it just feels as though the
flurry of opinions have been made and argued either way), and I'm
hoping that everyone can have a think about where and how they'd like
to see this move forward (if at all) between now and then. Given we've
only just hit alpha 1, I don't think we need to rush into a decision
right now for the sake of one.
I completely agree.
I would suggest one thing though. When it comes up for a vote, please
either make 2 questions:
- Should ext/mysql be hard-deprecated in 5.5
- Should ext/mysql be soft-deprecated in 5.5 and hard-deprecated in NEXT
Or 4 options to deprecation:
- Hard-deprecated in 5.5
- Soft-deprecated in 5.5 and hard-deprecated in NEXT
- Either
- Neither
That way both viewpoints can be voted on in one vote. And we can get an
accurate count of the thoughts...
Anthony
hi Anthony,
Adam,
My intention at this stage is to call a vote next Monday: it feels
like the discussion has mostly died down now (which isn't to say I
think we're at a consensus necessarily — it just feels as though the
flurry of opinions have been made and argued either way), and I'm
hoping that everyone can have a think about where and how they'd like
to see this move forward (if at all) between now and then. Given we've
only just hit alpha 1, I don't think we need to rush into a decision
right now for the sake of one.I completely agree.
I would suggest one thing though. When it comes up for a vote, please
either make 2 questions:
- Should ext/mysql be hard-deprecated in 5.5
- Should ext/mysql be soft-deprecated in 5.5 and hard-deprecated in NEXT
Or 4 options to deprecation:
- Hard-deprecated in 5.5
- Soft-deprecated in 5.5 and hard-deprecated in NEXT
- Either
- Neither
That way both viewpoints can be voted on in one vote. And we can get an
accurate count of the thoughts...
Hard/soft deprecated?
I suppose by "soft" you mean not actually deprecated but only
documented as such?
The on connect only notice is rather soft, tbh :)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre,
Hard/soft deprecated?
I suppose by "soft" you mean not actually deprecated but only
documented as such?
Correct. Hard = raising E_DEPRECATED from code. Soft = Documentation and PR
only...
On Mon, Nov 19, 2012 at 5:04 AM, Anthony Ferrara ircmaxell@gmail.comwrote:
Pierre,
Hard/soft deprecated?
I suppose by "soft" you mean not actually deprecated but only
documented as such?Correct. Hard = raising
E_DEPRECATEDfrom code. Soft = Documentation and PR
only...
By "NEXT" are you referring to 6.0 or 5.6?
Also, can you add an option for raising E_DEPRECATED in 5.5 then removing
support altogether in 6?
--Kris
Kris,
By "NEXT" are you referring to 6.0 or 5.6?
Whatever the release after 5.5 is. Be it 5.6, or 6.0, NEXT indicates the
next temporal release...
Also, can you add an option for raising
E_DEPRECATEDin 5.5 then removing
support altogether in 6?
That's already in there. That's what I mean by hard-deprecating it for
5.5...
And in either case, removal would happen one release after hard
deprecation...
Anthony
And in either case, removal would happen one release after hard
deprecation.
I'd actually propose that it is removed in PHP 6, even if there is PHP
5.6 and 5.7, etc. Something can be deprecated for several versions.
It is a significant change that seems more suited to a major release
such as 6.0.0.
This is slightly off-topic since this is about when we deprecate, not
when we remove.
On Mon, Nov 19, 2012 at 9:49 AM, Levi Morrison morrison.levi@gmail.comwrote:
On Mon, Nov 19, 2012 at 10:22 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:And in either case, removal would happen one release after hard
deprecation.I'd actually propose that it is removed in PHP 6, even if there is PHP
5.6 and 5.7, etc. Something can be deprecated for several versions.
It is a significant change that seems more suited to a major release
such as 6.0.0.This is slightly off-topic since this is about when we deprecate, not
when we remove.
I think they kinda go hand-in-hand though. And yes I agree; 6.0 should be
the target for removal. In fact, I'm of the opinion that everything that
was hard-deprecated in 5.x should be removed completely in 6.0. People
understand that some BC will occur in major version increments. Adoption
would and should be a gradual process for that reason as people update
their code to the latest standards. It also gives us the freedom to make
more fundamental improvements to the language if deemed necessary.
--Kris
hi Anthony,
Kris,
By "NEXT" are you referring to 6.0 or 5.6?
Whatever the release after 5.5 is. Be it 5.6, or 6.0, NEXT indicates the
next temporal release...Also, can you add an option for raising
E_DEPRECATEDin 5.5 then removing
support altogether in 6?That's already in there. That's what I mean by hard-deprecating it for
5.5...And in either case, removal would happen one release after hard
deprecation...
I do not follow the logic. It is too heavy to use the right
deprecation flag for the connect function only, but it is perfectly
fine to kill one of the most widely used extension in php history in a
minor version? I'd rather go with the flag and kill it in 6.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I just want to place a notice. Please visit http://de1.php.net/manual/de/function.mysql-query.php
The "suggested alternatives" are still not shown in all translated versions of the docs. I am sure that there are people who look in the docs but have never seen the suggestions before (like me)... I was forced to use PDO because of several frameworks and learned the advantages ;-)
Best regards
Christian
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, November 20, 2012 9:29 AM
To: Anthony Ferrara
Cc: Kris Craig; Adam Harvey; Chad Emrys; Patrick Allaert; internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: ext/mysql deprecation
hi Anthony,
Kris,
By "NEXT" are you referring to 6.0 or 5.6?
Whatever the release after 5.5 is. Be it 5.6, or 6.0, NEXT indicates the
next temporal release...Also, can you add an option for raising
E_DEPRECATEDin 5.5 then removing
support altogether in 6?That's already in there. That's what I mean by hard-deprecating it for
5.5...And in either case, removal would happen one release after hard
deprecation...
I do not follow the logic. It is too heavy to use the right
deprecation flag for the connect function only, but it is perfectly
fine to kill one of the most widely used extension in php history in a
minor version? I'd rather go with the flag and kill it in 6.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
My intention at this stage is to call a vote next Monday: it feels
like the discussion has mostly died down now (which isn't to say I
think we're at a consensus necessarily — it just feels as though the
flurry of opinions have been made and argued either way), and I'm
hoping that everyone can have a think about where and how they'd like
to see this move forward (if at all) between now and then. Given we've
only just hit alpha 1, I don't think we need to rush into a decision
right now for the sake of one.I completely agree.
I would suggest one thing though. When it comes up for a vote, please either
make 2 questions:
- Should ext/mysql be hard-deprecated in 5.5
- Should ext/mysql be soft-deprecated in 5.5 and hard-deprecated in NEXT
Or 4 options to deprecation:
- Hard-deprecated in 5.5
- Soft-deprecated in 5.5 and hard-deprecated in NEXT
- Either
- Neither
That way both viewpoints can be voted on in one vote. And we can get an
accurate count of the thoughts...
I've been mulling this for a couple of days, and Anthony and I have
talked about this on IRC, and I'd prefer to have two questions:
-
Should ext/mysql generate
E_DEPRECATEDnotices in PHP 5.5? (yes/no) -
If we decide not to generate
E_DEPRECATEDnotices in PHP 5.5, what
should the next course of action be:
(a) Enhance the manual text to make the soft deprecation clearer,
and generateE_DEPRECATEDnotices in PHP 5.6
(b) Enhance the manual text to make the soft deprecation clearer,
but take no further action in terms ofE_DEPRECATEDfor the forseeable
future
(c) Remove the warnings from the manual and undeprecate ext/mysql entirely
The reason for this is that I'd like to make the vote about the actual
RFC (E_DEPRECATED in 5.5) as clear as possible. I'm worried that a 3
or 4 option vote there could easily lead to a split decision, which
will make it very difficult to take any sort of decisive action. I'd
rather make a decision there, then we can look at what action would be
preferred if the RFC itself fails.
Just to be clear: I don't think that "do nothing" is a very useful
option for the second question, which is why I've omitted it — it
doesn't seem like anyone's particularly satisfied with the current
state of affairs.
Thoughts?
Adam
My intention at this stage is to call a vote next Monday: it feels
like the discussion has mostly died down now (which isn't to say I
think we're at a consensus necessarily — it just feels as though the
flurry of opinions have been made and argued either way), and I'm
hoping that everyone can have a think about where and how they'd like
to see this move forward (if at all) between now and then. Given we've
only just hit alpha 1, I don't think we need to rush into a decision
right now for the sake of one.I completely agree.
I would suggest one thing though. When it comes up for a vote, please either
make 2 questions:
- Should ext/mysql be hard-deprecated in 5.5
- Should ext/mysql be soft-deprecated in 5.5 and hard-deprecated in NEXT
Or 4 options to deprecation:
- Hard-deprecated in 5.5
- Soft-deprecated in 5.5 and hard-deprecated in NEXT
- Either
- Neither
That way both viewpoints can be voted on in one vote. And we can get an
accurate count of the thoughts...
I've been mulling this for a couple of days, and Anthony and I have
talked about this on IRC, and I'd prefer to have two questions:
Should ext/mysql generate
E_DEPRECATEDnotices in PHP 5.5? (yes/no)If we decide not to generate
E_DEPRECATEDnotices in PHP 5.5, what
should the next course of action be:
(a) Enhance the manual text to make the soft deprecation clearer,
and generateE_DEPRECATEDnotices in PHP 5.6
(b) Enhance the manual text to make the soft deprecation clearer,
but take no further action in terms ofE_DEPRECATEDfor the forseeable
future
(c) Remove the warnings from the manual and undeprecate ext/mysql entirelyThe reason for this is that I'd like to make the vote about the actual
RFC (E_DEPRECATED in 5.5) as clear as possible. I'm worried that a 3
or 4 option vote there could easily lead to a split decision, which
will make it very difficult to take any sort of decisive action. I'd
rather make a decision there, then we can look at what action would be
preferred if the RFC itself fails.Just to be clear: I don't think that "do nothing" is a very useful
option for the second question, which is why I've omitted it — it
doesn't seem like anyone's particularly satisfied with the current
state of affairs.Thoughts?
Adam
Has 2(c) been even suggested?
I take at that 2(b) is for those advocating "Move to PECL with no
E_DEPRECATED notices being thrown"?
Cheers,
David
- If we decide not to generate
E_DEPRECATEDnotices in PHP 5.5, what
should the next course of action be:
(a) Enhance the manual text to make the soft deprecation clearer,
and generateE_DEPRECATEDnotices in PHP 5.6
(b) Enhance the manual text to make the soft deprecation clearer,
but take no further action in terms ofE_DEPRECATEDfor the forseeable
future
(c) Remove the warnings from the manual and undeprecate ext/mysql
entirelyHas 2(c) been even suggested?
Not that I've seen, but having a "none of the above, I want none of
this" option seems prudent.
I take at that 2(b) is for those advocating "Move to PECL with no
E_DEPRECATEDnotices being thrown"?
Not really. We can't really unbundle and move to PECL without
deprecating first anyway, IMO. It's basically the option for no real
change but clarifying the manual wording, since nobody seems satisfied
with it.
Or, to put it another way from where I sit: the "too hard, let's make
a decision after stringing people along longer" option.
Adam
- If we decide not to generate
E_DEPRECATEDnotices in PHP 5.5, what
should the next course of action be:
(a) Enhance the manual text to make the soft deprecation clearer,
and generateE_DEPRECATEDnotices in PHP 5.6
(b) Enhance the manual text to make the soft deprecation clearer,
but take no further action in terms ofE_DEPRECATEDfor the forseeable
future
(c) Remove the warnings from the manual and undeprecate ext/mysql
entirely
Has 2(c) been even suggested?
Not that I've seen, but having a "none of the above, I want none of
this" option seems prudent.
Except it's "lets reverse the changes already made", not "none of the
above".
I take at that 2(b) is for those advocating "Move to PECL with no
E_DEPRECATEDnotices being thrown"?
Not really. We can't really unbundle and move to PECL without
deprecating first anyway, IMO. It's basically the option for no real
change but clarifying the manual wording, since nobody seems satisfied
with it.
No other extension was deprecated before moving to PECL, so why the
extra hurt for ext/mysql? As I've said before, it doesn't makes sense to
have it throw notices while it's in core, then no longer throw notices
once moved to PECL. If the plan is to drop it completely, and not move
it to PECL, then deprecation notices do make sense as there's no other
recourse once the extension is removed.
In that case we really should have 3 questions:
Should ext/mysql generate E_DEPRECATED notices in PHP 5.5? (yes/no)
Should ext/mysql be moved to PECL or dropped completely in the future
(PECL/dropped)
Should the manual text be changed to make soft deprecation clearer? (yes/no)
Or, to put it another way from where I sit: the "too hard, let's make
a decision after stringing people along longer" option.Adam
Cheers,
David
David Muir wrote:
No other extension was deprecated before moving to PECL, so why the extra hurt
for ext/mysql? As I've said before, it doesn't makes sense to have it throw
notices while it's in core, then no longer throw notices once moved to PECL. If
the plan is to drop it completely, and not move it to PECL, then deprecation
notices do make sense as there's no other recourse once the extension is removed.In that case we really should have 3 questions:
Should ext/mysql generate
E_DEPRECATEDnotices in PHP 5.5? (yes/no)
Not that I'm allowed, but the more I look at this 'no' is the right answer!
Should ext/mysql be moved to PECL or dropped completely in the future
(PECL/dropped)
Since most distros DON'T follow the bundling that PHP itself proposes they will
continue to include mysql anyway? The situation would then be no different to
that when mysql was dropped as enabled by 'default' and so users had to be TOLD
how to enable it again. THIS is the point at which mysqli is then recommended as
an alternative?
Should the manual text be changed to make soft deprecation clearer? (yes/no)
There is some good 'upgrade' documentation. If that is not going to be brought
up to date where it is currently, could the author/owner be asked to allow it to
be moved to php.net where it can be used as the base for that essential guide?
My own interest here is that I NEED a good reference to make the changes needed
for sites and so people are saying that the currently identified document is out
of date?
If distros add mysql into their installations going forward it is their problem
to maintain it. Just the same as other extensions that are still available via
the same route?
Including mysql in the windows distros is probably where most new users will be
starting from? So again not enabling them is another flag point ...
--
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
We can't really unbundle and move to PECL without
deprecating first anyway
For the record, we did this with other extensions in the past.
Technically mysql isn't any different, we only make a more careful approach
because ext/mysql "just works" and it is widely used.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Just to be clear: I don't think that "do nothing" is a very useful
option for the second question, which is why I've omitted it — it
doesn't seem like anyone's particularly satisfied with the current
state of affairs.
I still think this is useless, but have been convinced off list we
should have it. So add 2(d): "do absolutely nothing".
Adam