Re: pdo driver levels

From: Date: Wed, 04 Jan 2006 15:25:58 +0000
Subject: Re: pdo driver levels
References: 1 2 3 4 5 6  Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-3389@lists.php.net to get a copy of this message
On 1/4/06, Lukas Smith <lsmith@php.net> wrote: > 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 .. Doh! Yes, of course. > > 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? Yes, but knowing that it's emulated doesn't help you do anything about the bug or using the feature. > also someone may be particularily interested in the performance benefits > (versus the sql injection protection). I think this aspect will be hard to quantify. > 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). Hmm. Broadly speaking, the things that you're likely to need to know about are implied by the driver name. > > 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. That sounds like it will have definite positive results in a much shorter timespan :) > > (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. The more control that the abstraction has over the SQL, the more things it can handle more transparently. I've tried to keep PDO well away from this stuff because it is impossible to get it 100% correct. > 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. Great :) --Wez.

« previous php.pecl.dev (#3389) next »