Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71533 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 72178 invoked from network); 24 Jan 2014 21:19:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Jan 2014 21:19:24 -0000 Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.216.174 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.216.174 mail-qc0-f174.google.com Received: from [209.85.216.174] ([209.85.216.174:57384] helo=mail-qc0-f174.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BB/2A-21270-9D8D2E25 for ; Fri, 24 Jan 2014 16:19:22 -0500 Received: by mail-qc0-f174.google.com with SMTP id x13so5043877qcv.19 for ; Fri, 24 Jan 2014 13:19:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=6MixHv3GiB0of6sa8SPTg3nEWRnVqifU7Q99TUUMQfU=; b=HBhBoUMWkEDH9KaQ/fsxy0edu8NJCxJhZNIPH2tlmHoHbAy0AFPbwiBCKx/yyp9SIc nfRSGjcXrupv2tHmQye0wju1u0PxnOBvx7s62hE9V2NhIl4mN6hcjkCC+V0ciiGLVtkN LUF/AH8FVJi9zyHQf7X20mmnW0IoD4fdMjSo/TxKiS+lWWsBpJX+s+BIWVfF6LstGG+H 2bzGJLv6AntA8+eShYautvRUqJ6BvrvS1aJgqUcbWC8yP2q7MW1qaHlBPUD11e2bN7P5 HqaMS8T5bCzJOTD0l95UvfOMT726mYAgDVUHsRRJse3Oiaxsk++OMhBSiWuaO92nhQZ2 9ttw== X-Gm-Message-State: ALoCoQnypVLmbU6WfLas4QYjD6vt1OWpFLooknHsQxEs664S3Yoc3oW7AAra9lx+z2xYb588DdUf X-Received: by 10.140.38.11 with SMTP id s11mr22423940qgs.62.1390598358628; Fri, 24 Jan 2014 13:19:18 -0800 (PST) Received: from [192.168.200.30] (c-50-131-44-225.hsd1.ca.comcast.net. [50.131.44.225]) by mx.google.com with ESMTPSA id o68sm1677500qge.8.2014.01.24.13.19.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Jan 2014 13:19:15 -0800 (PST) Message-ID: <52E2D8D2.80106@lerdorf.com> Date: Fri, 24 Jan 2014 13:19:14 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Arvids Godjuks , PHP Internals References: <52E29253.2000801@lsces.co.uk> <52E2924B.6080002@ajf.me> <52E299D4.6040102@garfieldtech.com> <52E2C98C.6010005@lerdorf.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jcjIGQuI7EsSRE02JLMhOsrTUlP5w5B4c" Subject: Re: [PHP-DEV] Ruminations on PHP 5++ From: rasmus@lerdorf.com (Rasmus Lerdorf) --jcjIGQuI7EsSRE02JLMhOsrTUlP5w5B4c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 1/24/14, 1:03 PM, Arvids Godjuks wrote: > The PDO. This is something that needs so much improvement that it's > ridicilous it has survived till this time. I use Yii framework as my to= ol, > they use PDO as their base. I have considered many times to integrate a= > mysqli to PDO wrapper to bring things like mysqli_ping, unbuffered quer= ies > and lost more. At this point I can do without those things because I do= not > have a lot of load on my projects, but they are growing and at some poi= nt > abandoning the PDO will be a nesesity due to it's lack of features. > I think PDO is a bad idea for PHP as a whole. We are better of with a > consisten API through the native drivers and maybe a PDO like thing tha= t > gives us data objects, but still provides ability to get to the low lev= el > stuff that is sometimes needed. PHP lately has moved to projects that > previosly where done on Java and some other move advanced tech. And lac= k of > frameworks using the native drivers is kind'a bad, because in really > advanced projects you have to create your own framewok... But note, if you blindly switch from PDO to mysqli, which in turn usually means moving from client-side prepares to server-side prepares, chances are you are going to take a significant performance hit. Like I said, it means two extra network roundtrips per sql query and for one large project I worked on that meant an extra 40ms latency per web reques= t. So I don't think PDO is a bad idea. Having a single source of common functionality needed by all DB drivers makes sense. Imagine if every lower-level driver needed to implement their own client-side prepare feature? And a consistent API across the low-level drivers isn't feasible since each DB has a lot of specialization. It would end up looking exactly like PDO but with a bunch of special calls for each one. If you could bounce back and forth between PDO and the lower-level driver easily you get the consistent API and you get access to all the lower-level features. Also, from a migration point of view, scrapping PDO and rewriting all the low-level drivers to be "consistent" would be an absolute nightmare. -Rasmus --jcjIGQuI7EsSRE02JLMhOsrTUlP5w5B4c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlLi2NIACgkQlxayKTuqOuADJgCeMwTl20Ee5dJF7LoUU4FscS1V sMUAn21gauVE+re1ahZ/EwhCRKJBE7H1 =Bvdk -----END PGP SIGNATURE----- --jcjIGQuI7EsSRE02JLMhOsrTUlP5w5B4c--