Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63954
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.184 cause and error)
Message-ID: <50A7C72A.3040701@lsces.co.uk>
Date: Sat, 17 Nov 2012 17:19:38 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120826 Firefox/15.0 SeaMonkey/2.12
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
References: <CADajX4CYZdNpgQv46m_6J7tQLBc=h6HxCn-bGpxr3Ou2VaqgBg@mail.gmail.com> <50A30144.5070305@phpgangsta.de> <50A3BEC0.8030607@gmail.com> <CAET_qdMmhRyidM6_VOokBu6tYvgrPHMOPdzz0PaFpxc3NaTdYQ@mail.gmail.com> <CADajX4Bh+5YrCPEFLzC2qqeJ4NnADbBV0u+wByz3Kb7Jp45KOw@mail.gmail.com> <50A54713.8090102@sugarcrm.com> <CAArmra2bjj3y2UUV8nszU74tN9o4VvB67aXzq5Z1cE2Y_tVijg@mail.gmail.com> <50A549EB.2020408@lerdorf.com> <CAArmra2BCmbOjkK0D8gKc5o0Pwhx0jNGi-3m2C2Z2dAnb0yv7w@mail.gmail.com> <CAAyV7nGMi20xjBYbouvsyUrxdOSuboP6u-guY9DX8qkSagQbjg@mail.gmail.com> <CAL+t6cEfDPT_-td5Ts4-SpNowSK9GJAq71KPKU-5ZUP2yzsNjw@mail.gmail.com> <CAAyV7nF=gMzD6rHUW2mffXv9uc-sSuO3cX=kyMnt81bUZH_VtQ@mail.gmail.com> <CAL+t6cFY5vPERz58foLh01ori68euYbSg-LGcjOsm9cgeNAs2A@mail.gmail.com> <50A58828.4070701@lerdorf.com> <CAL+t6cEZur=Eig6+0LzrdOWRRonSbUGV-eMeg7iyMA2bcZrvwA@mail.gmail.com> <50A59E24.4060704@lerdorf.com> <50A68146.4020603@lsces.co.uk> <CAKOpQSw-4nN_nC0xQW2LzgwM2TohNd76a1iJHXwusMPiDUq=gg@mail.gmail.com>
In-Reply-To: <CAKOpQSw-4nN_nC0xQW2LzgwM2TohNd76a1iJHXwusMPiDUq=gg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: ext/mysql deprecation
From: lester@lsces.co.uk (Lester Caine)

Kris Craig wrote:
> There is something really important I'd also like to stress:  In UPGRADING, as
> well as any other literature we release designed to help people with this
> transition, we should not simply focus on porting ext/mysql code to mysqli.  We
> should emphasize the use of prepared statements and fully integrate that into
> any tutorials we put out there.  There are too many PHP devs out there who don't
> even know what prepared statements are and their ported mysqli code will reflect
> this if we're too lax on this point.  Rasmus is right about asynchronous queries
> and other features being really helpful as well, but I think prepared statements
> stand apart because they prevent what is currently one of the most common
> security vulnerabilities on the web today.

This also sidesteps the status of PDO and highlights why we need to re-assess 
that as well. PDO was supposed to replace all database drivers with a common 
framework, but aspects being extolled for mysqli also apply to other engines for 
which PDO becomes a straight jacket? The proliferation of libraries either still 
using generic drivers or providing a poor abstraction layer because of the 
limits of PDO would be served better by not simply replacing mysql by mysqli in 
some examples. ADOdb still provides an ideal base which switching from one 
driver to another simply works, even using PDO as an alternative to the generic 
driver, where mysql to mysqli is just a matter of switching the driver name.

-- 
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