Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:31456 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 96121 invoked by uid 1010); 4 Aug 2007 06:22:00 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 96106 invoked from network); 4 Aug 2007 06:22:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Aug 2007 06:22:00 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.145 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 213.123.20.145 c2bthomr13.btconnect.com Received: from [213.123.20.145] ([213.123.20.145:13245] helo=c2bthomr13.btconnect.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 41/C1-05091-50B14B64 for ; Sat, 04 Aug 2007 02:21:58 -0400 Received: from [127.0.0.1] by c2bthomr13.btconnect.com with ESMTP id DCS71139; Sat, 4 Aug 2007 07:17:32 +0100 (BST) Message-ID: <46B41A47.1080902@lsces.co.uk> Date: Sat, 04 Aug 2007 07:18:47 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070716 SeaMonkey/1.1.3 MIME-Version: 1.0 To: PHP internals References: <87E4F8AF-06DE-4FCC-AD1B-83E932A5E180@prohost.org> <46B2DDDB.6020801@lsces.co.uk> <46B2E196.4080400@zend.com> <46B2FF97.3080302@lsces.co.uk> <46B3049E.5080309@zend.com> <46B37FBB.5030803@quipo.it> <46B382E6.9000600@lsces.co.uk> <46B39172.6060300@lsces.co.uk> <46B393DA.7090207@oracle.com> In-Reply-To: <46B393DA.7090207@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] 5.2.4RC1 Released From: lester@lsces.co.uk (Lester Caine) Christopher Jones wrote: > > Lester Caine wrote: >> I keep being told that the PDO drivers can be extended to include all >> of the things already available in the native driver, but the second >> you do that they become incompatible, so in addition to the PDO driver >> you need to also run the native driver simply to provide the areas NOT >> covered by PDO. We need a generic framework that addresses the real >> problems not one that creates an artificial lowest common denominator >> strangle hold :( PDO could evolve into that, but not with it's current >> restrictions. > Can you list the current restrictions as you see them? Actually the very first one has been addressed and has nothing to do with PDO. Up until recently is was essential to provide backwards compatibility with PHP4 and all of the projects I currently work with WOULD still install on PHP4. Although *I* never used it in production, the continued support meant that there was a large base that insisted on retaining it. So ADOdb's continued underlying support for PHP4 is useful and until there are a higher percentage of PHP5 users than PHP4 - PDO takes second place as it is not available on a large number of hosts? The next problem builds on the above one. From the PDO manual "PDO does not provide a database abstraction; it doesn't rewrite SQL or emulate missing features. You should use a full-blown abstraction layer if you need that facility." ADOdb will run PDO drivers quite happily, but on current information the performance of the PDO drivers is slower than using the same native driver. So given a choice the native one is preferable and currently essential for PHP4 support. NEITHER of the above are restricted to Firebird and apply equally to all databases, but they are the main reason to date that no one has had the inclination to fix the pdo_firebird driver as it's deployment potential is currently limited. The internals of PDO restrict things to using SQL access to the database. While it will probably be said that the database should ONLY provide SQL access to everything, Firebird has a services interface which is used for such things as backup, user management, and the event handler. How should all those be handled if they are moved to the PDO driver? PDO provides a basic transaction control that hides the transaction modes. It can't handle retaining the context of the transaction following a commit or roll back, or selection a more appropriate transaction mode? CONCURRENCY for reports at a fixed time point over COMMITTED to handle changes made in other transactions. How does one switch between a 'wait' and 'nowait' transaction? The one that prompted this discussion. How do you return a simple handle to a BLOB object so that you DON'T have to download the whole blob. It can be useful to hold the blob id so that you only access a sub set of the data from the blob object. This seems to be missing in PDO? HAVING to maintain PHP4 support has meant that I have not gone into PDO with a fine tooth comb, and most of my understanding of the problems of PDO is based on what has been said elsewhere, but at present I can't see how some of these fundamental facilities provided by the php_interbase driver would be mirrored in PDO. I stand to be corrected, and perhaps when PHP4 has died THEN the supposed advantage of PDO may be a more attractive development path? But at present there is simply no incentive to move over :( -- Lester Caine - G8HFL ----------------------------- Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php