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 the API too much and make things harder in the future for when those databases grow and add new features.
I see, and I understand that it's pointless to add features to a general purpose framework that can only be supported by a single implementation. Still, it would be nice to have a syntax that can basically allow both.
The current transactional behaviour of PDO is this, FYI, a fairly standard semantic:
- new connections start in auto-commit mode (ala ODBC)
> - in auto-commit mode, there is an implicit commit after each query
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]
- if you begin a txn in auto-commit mode, auto-commit is disabled until you rollback or commit. - it is an error to begin a new transaction while inside a transaction, since nested transactions are not portable
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)
- 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
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 ?
Right now, I think I would prefer to defer making a decision on multi-connection transactions, with a view to implementing it as a separate API (pdo_multi_txn_begin() or something like that) so that it is clear that it operates on separate connections. If it does appear that only firebird supports this, then I would prefer to have that function in the pdo_firebird extension only, at least until other databases appear and we can see how their API operates and find some common ground.
I was merely suggesting we'd look for a way to design the API in such a way that the transaction is not a [singular] property of a connection; if we end up introducing a transaction interface, I would like its dbh property to allow multiple values as well [for the reasons I have pointed out]
Does this cause a big problem for using firebird in PHP? (How often do you open separate connections to separate databases?)
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.
- executing SQL with placeholders directly,
This is already implemented, although one-shot with placeholders is not yet.
This feature is not as pointless as some people may think. Even if you execute a query only once, you won't be forced to [add|strip]_slashes() strings or decide whether or not to add quotes.
- returning information on placeholders in a prepared statement (type),
Just wondering, how often do you need to query the types of placeholders? PDO works in the opposite sense: you tell the database the type you are setting and intending to receive.
Well, Firebird knows the types of its params and fields, so there's no need to specify them when binding params. The opposite would only be of use if you want to analyze an unknown (user-provided) query. [which, I agree, won't happen that often]
- adding/removing users, stopping/restarting & other maintenance stuff.
These can (perhaps should) be extension level functions and not methods of the PDO class, unless they happen to be uniform API's across the majority of APIs.
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.
-- Ard
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
