Re: pdo driver levels

Wez Furlong wrote:

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.

you mean myisam? .. but i get what you mean ..

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.

well don't we have a suspended bug where emulation is having issues? also someone may be particularily interested in the performance benefits (versus the sql injection protection).

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).

Yeah. I got things sort of working on MDB2, but far from ideal.

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.

Again I am just talking about features implemented. The driver level does not translate to "will be portable across all drivers with the same level". It just means the features are implemented and so its reasonable to expect that with some handling of tricky cases I can expect the API to support everything I need (obviously the SQL will likely to need some massaging on top of that).

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.

Ok, maybe finding such a driver level is unrealistic and the "proper" course of action is to one by one beef up the driver specific documentation.

(isn't that what MDB2 is for? :-)

Yeah well MDB2 is in a similar situation, abeit more things will "work" across drivers obviously. But even there some features are server version dependent. But maybe its more feasible to do this driver level thing for MDB2 drivers than PDO. I just need to find the time to start writing PDO based drivers :-/ Actually I started the other day, hopefully I have something by the end of the month. regards, Lukas