Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31490
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.134 cause and error)
Message-ID: <46B982D7.4020702@lsces.co.uk>
Date: Wed, 08 Aug 2007 09:46:15 +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>	 <46B41A47.1080902@lsces.co.uk> <46B81302.1060403@lsces.co.uk>	 <200708072345.58330.larry@garfieldtech.com>	 <46B94F8C.9030105@pooteeweet.org> <fbb0d11d0708072237q5cd83632sa5a7fa942676a0de@mail.gmail.com> <46B972C6.2070803@lsces.co.uk> <46B9742F.8050701@pooteeweet.org>
In-Reply-To: <46B9742F.8050701@pooteeweet.org>
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)

Lukas Kahwe Smith wrote:
> Lester Caine wrote:
>> Dan Scott wrote:
>>> Right. And Wez posted this (partially in reply to Lester's almost
>>> identical hysterics at that time) on this very list ages ago
>>> (http://news.php.net/php.internals/14937 - Feb 14, 2005, to be exact):
>>>
>>> BEGIN QUOTE:
>>> Drivers are free(*) to implement driver specific methods on the PDO
>>> and PDOStatement objects, provided they are "namespaced"
>>>
>>> eg:
>>>
>>> $db->mysqlDoSomething()
>>>
>>> would be a mysql driver specific feature.
>>>
>>> More generic attributes can be accessed or set via the 
>>> get/setAttribute methods.
>>>
>>> (*) while they are "free" to do so, it's better to discuss the feature
>>> first to see if it can be made into a more generic feature of PDO
>>> itself
>>> END QUOTE
>>
>> NOTE the (*) - I'm TRYING to reopen the discussion on generic things 
>> like transaction handling. Simply bolting driver specific solutions 
>> back into each different driver in a different way is pointless? We 
>> have those drivers already? The extra's are less of a problem than 
>> missing CORE facilities :(
> 
> Ok, yes this is indeed an issue. PDO does not support nested 
> transactions. No other RDBMS that I am aware of supports this and for 
> all I know it does not work in the ibase driver either. Atleast we tried 
> to use it in MDB2 and never got it to work. Ask Lorenzo for details on 
> this.
> 
> However again it does not prevent firebird specific methods for handling 
> nested transactions, which an abstraction layer author may then choose 
> to use in a firebird driver.

You are going beyond where I've got to ;)

I'm just looking to be able to select auto commit on or off, and switch 
transaction modes. Something which many 'proper' databases support but which I 
do note that other generic drivers only make this available via the connect 
string, something which explains why I get different results when changing 
from Firebird within ADOdb. I'm simply used to wrapping an update in it's own 
transaction, which can be rolled back and then reworked if required.

I will be honest here - never using other databases *IN* PHP other than via 
ADOdb, I had not appreciated that many of the native drivers simply don't 
provide access to facilities that I KNOW exist in those databases themselves! 
This probably explains why I get such blank responses when trying to get 
things sorted.

ibase_trans allows me to set up a package of work on the database, set up the 
type of transaction ( something that I KNOW Oracle, DB2 and MsSQL internally 
support ). I can build a set of report results using 'concurrency' isolation 
level get the results and post them back to the database in a second 
transaction, or I can wait on other activity completing before posting the 
changes. I think that I had not appreciated that the Oracle, DB2 and MsSQL 
drivers have to create a new connection for a new transaction :(

( I'll answer the point on the other post separately - at least *I* am 
beginning to understand how restrictive the PHP interface is to other database 
users and that explains why there have been such differences of opinion in the 
past ;) )

-- 
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