Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31473
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.146 cause and error)
Message-ID: <46B81302.1060403@lsces.co.uk>
Date: Tue, 07 Aug 2007 07:36:50 +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 <internals@lists.php.net>
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> <fe05d1540708031240p391d0d1crb287b3e23112a115@mail.gmail.com> <46B39172.6060300@lsces.co.uk> <46B393DA.7090207@oracle.com> <46B41A47.1080902@lsces.co.uk>
In-Reply-To: <46B41A47.1080902@lsces.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PDO Restriction ( was 5.2.4RC1 Released )
From: lester@lsces.co.uk (Lester Caine)

Lester Caine wrote:
> 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 :(

Things went quiet :(

Is there anything in my above list this is NOT correct? I do stand to be 
corrected about PDO, but at present I can't see how to get around the 
limitations even IF the pdo_firebird driver was functional. And I see some of 
these restrictions applying to other database engines as well?

-- 
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