Re: [PDO] Asynchronous requests
[email protected] (Lukas Kahwe Smith) Tue, 3 Nov 2009 14:20:58 +0100
| Newsgroups | php.pdo |
|---|---|
| Message-ID | <[email protected]> |
On 03.11.2009, at 14:08, Johannes Schlüter wrote: > On Tue, 2009-11-03 at 13:52 +0100, Lukas Kahwe Smith wrote: >> On 03.11.2009, at 11:49, Johannes Schlüter wrote: >> >>> And even then PDO should be generic and do stuff the same way with >>> as >>> many drivers as possible. That's the point of abstraction. Different >>> databases, client-server protocols, client libraries, ... offer >>> different functionality which sometimes can't be emulated properly. >>> The >>> aim of abstraction is that I can - as simple as possible - switch >>> over >>> from one database to another, now consider having use async >>> switching >>> from psotgresql to sqlite (for whatever reason) - you have to change >>> the >>> whole architecture[1]. >> >> >> I am still not clear what you mean here. Do you think its impossible >> to abstract async? or do you want to limit PDO to functionality that >> is available on all drivers? > > I don't know enough about other databases to judge this. But if only > MySQL and PostgreSQL support it and then maybe in very different > ways I > see little sense in having it in an abstraction layer as emulating > this > (in a more or less sane way) is impossible. > > Having it optional with the given structure is stupid. > > Having it optional with another structure might probably be ok, but > then > it should be similar at least for databases which support it and not > be > implemented completely different for each and every. well one thing is clear .. PDO must make it possible for driver authors to support _all_ native functionality, regardless if other rdbms support the feature or not. where possible it can provide emulation. now the tricky thing is that a feature might be support by only one rdbms today, but that might change. i faintly remember that we already have some function that only works on one driver (we do have driver specific attributes already) and these should be prefixed with the name of the driver. now for features that are available on only a subset of rdbms, we need to figure out an approach. one approach would be that just as if the feature is only provided by a single driver, we prefix and wait until all (most?) rdbms support this so that we feel comfortable to provide a unified API. a problem can of course be if the API is not unifyable or maybe just for a subset of drivers. i think in this case we need to decide on a case by case basis if partial unification is ok, or if the driver that doesnt support the feature with the same api falls back to providing the given functionality with a prefixed method while throwing an error when calling the unified api. now the other question is if all of the above fits into the current pdo architecture. regards, Lukas Kahwe Smith [email protected]