Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63847
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nFOGa7UVALSQyAs-A+R0kuEmXoHPrxvCXNBnzAxLy0dww@mail.gmail.com>
References: <CADajX4CYZdNpgQv46m_6J7tQLBc=h6HxCn-bGpxr3Ou2VaqgBg@mail.gmail.com>
 <50A10A9D.9070402@oracle.com> <CAAyV7nF2tt6HtFZKevH_2kknqOvEmLJjEOF2_Bn_VHaZFUJERw@mail.gmail.com>
 <CAPwsocH3_qHSZbLFe27qX+KgBAC1D8KhwLi+PLHW503sCTBtTw@mail.gmail.com>
 <50A1946F.8010407@lerdorf.com> <50A20CCB.8090909@lsces.co.uk>
 <8A8A29F9E43E417FB5450D63019B2DDB@NeiRoze> <8f4231fc-6e3c-4a33-af71-2af5e7a95dfd@email.android.com>
 <CAAyV7nFOGa7UVALSQyAs-A+R0kuEmXoHPrxvCXNBnzAxLy0dww@mail.gmail.com>
Date: Tue, 13 Nov 2012 18:28:39 +0200
Message-ID: <CAL0xaBHfzAEWzATbSNcUGzQMyaqfj5x212giPSdfnDKwbkDZYg@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>, 
	Reinis Rozitis <r@roze.lv>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=90e6ba6e8b604603f904ce62ea51
Subject: Re: [PHP-DEV] RFC: ext/mysql deprecation
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--90e6ba6e8b604603f904ce62ea51
Content-Type: text/plain; charset=UTF-8

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 (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
>

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.

--90e6ba6e8b604603f904ce62ea51--