Re: pdo driver levels

MySQL transaction support is another example of why this is hard. It's perfectly legal to begin a transaction and roll it back with the regular bdb tables. There is no way to know at the API level whether the transaction was really rolled back. Checking to see whether the prepare is native or not shouldn't make any difference to your code; PDO emulation is supposed to be transparent so that you should never have to care about it. If it isn't totally transparent, then I'd rather spend the effort on improving it than trying to find ways to express how well it is supported. In general, you're never really sure what a given database driver, client and server triplet support until you're connected and trying to do it. Catching the errors is the "best" (as in, most portable) way to find out if something will work. The usage of some features varies wildly between the different databases; LOBs for example. You need to completely change the way you write your queries if you're using LOBs with Oracle, Postgres or ODBC. The latter doesn't really have a LOB interface, and with postgres, there are two different types with radically different uses (you have to use totally different SQL to express your LOB manipulation). If someone can come up with some reasonable definitions as to what set of features are available, then we can have a look at implementing them. I suspect that this will be hard to do at the PDO level, because it is (very deliberately) not a SQL abstraction layer. I'd much rather see that kind of abstraction layer sit on top of PDO, accompanied by code that knows how to talk the native lingo of the underlying driver to query capabilities and that can generate appropriate SQL based on some higher level abstraction. (isn't that what MDB2 is for? :-) --Wez. On 1/3/06, Lukas Smith <lsmith@php.net> wrote: > Dan Scott wrote: > > > I believe it would be a mistake to label this as a "support level" of > > the PDO drivers--this would be an artificial goal. Instead, I should > > probably beef up the http://php.net/pdostatement-rowcount > > to better > > cover the different scenarios in which you need to know the results of > > the SELECT statement and provide portable suggestions for each > > scenario. > > Well this just hightlights the issue that was brought up that it may be > difficult to differentiate between server and driver features, > especially as server features change at any given version. > > So what I am proposing is something like: > "implemented in the driver" > > Maybe we can document some server version specifics on the docs for the > given driver, but its obviously impossible to give a driver a fixed > "level" given that they can work with different server versions. So does > that make the entire idea not feasible? > > regards, > Lukas > > -- > PECL development discussion Mailing List (http://pecl.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >