On May 23, 2004, at 2:55 PM, Ard Biesheuvel wrote:
George Schlossnagle wrote:
I don't get this question, can someone reiterate the full context of
it for me?
For instance, if you prepare the statement
"SELECT * FROM WHERE id=?"
Firebird can figure out the type of the 'id' param, meaning you don't
George Schlossnagle wrote:
I don't get this question, can someone reiterate the full context of it
for me?
For instance, if you prepare the statement
"SELECT * FROM WHERE id=?"
Firebird can figure out the type of the 'id' param, meaning you don't
have to bind it to a certain type, whereas the em
On May 23, 2004, at 1:39 PM, Ard Biesheuvel wrote:
Wez Furlong wrote:
PDO doen't separate the concept of a session or environment from a
connection
to a database. This is perhaps where you are finding the fault. The
thing is
that not all databases work in this way, so we've gone for the more
p
Wez Furlong wrote:
PDO doen't separate the concept of a session or environment from a connection
to a database. This is perhaps where you are finding the fault. The thing is
that not all databases work in this way, so we've gone for the more portable
approach again.
I see that, but my point is th
gt; Cc: Wez Furlong; 'Ard Biesheuvel'; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] RE: pdo design
>
> Andi Gutmans wrote:
> > Wouldn't that be kind of slow because we'd need to check
> the query for
> > these special cases?
> hehe :) - in comparison t
Andi Gutmans wrote:
Wouldn't that be kind of slow because we'd need to check the query for
these special cases?
hehe :) - in comparison to getting the data out of the database?
Regards
alan
Andi
At 09:12 AM 5/23/2004 +0800, Alan Knowles wrote:
Just a thought - feel free to ignore...
In dataobjects
Andi Gutmans wrote:
Wouldn't that be kind of slow because we'd need to check the query for
these special cases?
At 09:12 AM 5/23/2004 +0800, Alan Knowles wrote:
Just a thought - feel free to ignore...
In dataobjects rather than implement extra methods for transactions, I
just hooked into query
.
Wouldn't that be kind of slow because we'd need to check the query for
these special cases?
Andi
At 09:12 AM 5/23/2004 +0800, Alan Knowles wrote:
Just a thought - feel free to ignore...
In dataobjects rather than implement extra methods for transactions, I
just hooked into query
..
eg. $do->quer
George Schlossnagle wrote:
On May 22, 2004, at 9:12 PM, Alan Knowles wrote:
Just a thought - feel free to ignore...
In dataobjects rather than implement extra methods for transactions,
I just hooked into query
..
eg. $do->query('BEGIN') - turned off autocommit, and ran begin.
$do->query('ROLLBACK'
On May 22, 2004, at 9:12 PM, Alan Knowles wrote:
Just a thought - feel free to ignore...
In dataobjects rather than implement extra methods for transactions, I
just hooked into query
..
eg. $do->query('BEGIN') - turned off autocommit, and ran begin.
$do->query('ROLLBACK') or $do->('COMMIT'); - ran
Just a thought - feel free to ignore...
In dataobjects rather than implement extra methods for transactions, I
just hooked into query
..
eg. $do->query('BEGIN') - turned off autocommit, and ran begin.
$do->query('ROLLBACK') or $do->('COMMIT'); - ranit , then turned
autocommit back on
It seemed f
Ard Biesheuvel wrote:
Wez Furlong wrote:
You might turn commit() into a NOP and raise the error on rollback()
only, as it's the responsibility of the user to choose a DB that fits
his needs. This would enhance portability IMO
Doesnt sound like a good idea to me. Since the default is auto commit
> Currently, PHP/Interbase uses one implicit transaction for the entire
> request. I think that, by the nature of PHP, if transactions can be
> supported, they should span all the statements executed during a
> request. [which should still be committed if something goes
> wrong, but
> would
Wez Furlong wrote:
PDO tries (a bit) to keep things portable: if it's a method of the PDO or
PDOStatement classes, then you can be reasonably sure it's supported for a
given driver. That doesn't mean that I want to exclude all non-portable
behaviour, I just want to make sure that we don't overload
> Yeah I know, but the current code doesn't even allow multiple
> transactions against a single database on the same
> connection, does it ?
> Adding PDO_Transaction::start($db1[, $db2 ...]) for multiple
> databases
> would be nice too, but it's not as important. It's just that I think
> thi
On May 22, 2004, at 11:50 AM, Wez Furlong wrote:
Hey Ard,
When you say database, do you mean separate database connection, or
separate
named databases on the same connection?
PDO::beginTransaction() initiates a transaction for a given connection
($dbh)
in a more or less portable way. You're not
16 matches
Mail list logo
