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 portable
approach again.
I see that, but my point is that is it not very constructive to code PDO around the assumption that a connection can never have more than one transaction at any point in the future. The same goes for the number of connections involved in a single transaction. Maybe startTransaction could query the specific driver instead of disallowing multiple transactions altogether. I think portability should not limit versatility.
I agree with Ard, though I'm uncertain what a good solution is. Certainly plenty of database (Oracle included) have a notion of transactions existing in (possibly concurrent) sessions. Supporting this seems very beneficial. Supporting this without making more crap for the simpler databases is a bit tricky. At first glance I think something like this:
$dbh = new PDO(...);
$session = $dbh->newSession()
// $session is a cloned copy of $dbh in mysql, is a new session in oracle
I think some sort of support along these lines is good, though I imagine the above syntax has all sorts of problems.
No, it is important for the script to fail the moment it attempts to use
transactions on a non-transactional database, otherwise you risk writing
garbage to it, with no way to rollback.
I guess that's a matter of taste. There are more uses for transactions than being able to roll them back. I consider it good coding practice to group related updates, and execute them inside a transaction block. But this isn't a big issue.
I agree with Wez. Implicitly lying about your support for transactions is dangerous, I think.
You're right, most people will probably never connect to more than one database. It's still a nice feature, though. As far as the transaction are concerned, I think multiple [non-nested] transactions should really be allowed.How would that look in the script?
Transaction parameters can be used to tune the amount of possible concurrency between different requests. Being able to execute one statement inside a read-only transaction will allow the database
to optimize its locking behavior. Another point is the visibility of concurrent transactions: monitoring a logging table in a read-only read-committed transaction while executing updates in a concurrent snapshot read/write transaction can be very useful.
I agree on multiple transaction support. And why not nested, if the underlying database supports it (db4 does)?
Courtesy of George, we have emulation of placeholders for input parameters for
databases that lack it; it's used by pdo_mysql and pdo_pgsql.
OK, that's nice, but for instance, can we make sure that it's possible that the driver figures out what the param types are ? As Firebird is able to determine this by itself, without the need of specifying it.
I don't get this question, can someone reiterate the full context of it for me?
George
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
