> 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 maintain a consistent view of the database throughout > the request]
The semantic used by PDO (and the other transactional db's in PHP) is to rollback any pending transaction on rshutdown. > Multiple concurrent transactions are not necessarily nested. It is > perfectly legal in many RDBMSs to start two transactions against a > database (one could be read-only for instance, or use a different > isolation policy) You can do this in PDO, but require a separate $dbh for each transaction. 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. > > - if a driver does not support transactions, an exception is raised > > (regardless of your choice of error handling settings) when > you attempt to > > begin a transaction or disable auto-commit mode > > 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 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. > > The PDO philosophy on driver specific behaviour can be > generally summed up as: > > if you can't do it portably, use a driver/db specific API or query. > > Yeah, that brings up another point. > If you execute 'SET TRANSACTION ...' in Firebird, the result > will be a > transaction (handle). Do you think this will fit the current scheme ? 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. > 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? > I think most databases allow SQL statements to carry out these tasks, > which makes this one a non-issue. > > Did you have any plans on emulation layers for some of this > stuff ? For > instance, binding output params is [currently] not supported by > PHP/InterBase, but this is something that can easily be handled in a > generic way. 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. We also have generic binding to output columns handled by PDO itself. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
