Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31490
Return-Path:
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 81554 invoked by uid 1010); 8 Aug 2007 08:45:00 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 81538 invoked from network); 8 Aug 2007 08:45:00 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
by localhost with SMTP; 8 Aug 2007 08:45:00 -0000
Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.134 cause and error)
X-PHP-List-Original-Sender: lester@lsces.co.uk
X-Host-Fingerprint: 213.123.20.134 c2bthomr02.btconnect.com
Received: from [213.123.20.134] ([213.123.20.134:10277] helo=c2bthomr02.btconnect.com)
by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
id 36/23-46037-98289B64 for ; Wed, 08 Aug 2007 04:44:58 -0400
Received: from [127.0.0.1]
by c2bthomr02.btconnect.com
with ESMTP id GZB95914;
Wed, 8 Aug 2007 09:44:53 +0100 (BST)
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
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> <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