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.
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.
Database specific stuff again ;) I do intend to allow PDO to return this kind of structured value. Again, I'd like to build up a list of the kind of things that are reasonably portable before going into that aspect in great detail.
Yeah, I know, but now is our chance to think of a generic way to return other things than statement or result sets from a query execution. I'm not saying each and every driver should support it, I'm just suggesting we shouldn't disallow it altogether.
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.
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.
-- Ard
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
