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
Wez Furlong wrote:
When you say database, do you mean separate database connection, or separate
named databases on the same connection?
Well, first of all, Firebird does not distinguish between databases and
database connections. So connecting to several databases on the same
host is basically th
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
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 always guaranteed to be able to do
that; extending
18 matches
Mail list logo
