Re: [PDO] Asynchronous requests
[email protected] (Lukas Kahwe Smith) Tue, 3 Nov 2009 14:42:01 +0100
| Newsgroups | php.pdo |
|---|---|
| Message-ID | <[email protected]> |
On 03.11.2009, at 14:36, Johannes Schlüter wrote: > On Tue, 2009-11-03 at 14:20 +0100, Lukas Kahwe Smith wrote: >> 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. > > Is this clear? Is this a must? > I'm sure the will be database-specific extensions in the future, too. > I doubt a generic interface can stay clean while supporting all the > kinds of weird things database libs support. I think that would be insane in the long run. If this is really the case, we should drop PDO this very second and instead update MDB2 to run on top of PDO and ship it with PHP. >> 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. > [....] >> now the other question is if all of the above fits into the current >> pdo architecture. > > As I said before in this thread custom methods currently use a __call > () > like approach for adding methods. There is no way to check feature > availability at run time (except calling the method and see) which > means > that practically this is useless for a developer. > Currently there's not even a getCurrentDriver() method so one would > have to store the driver name when creating the class .. but even > then > it's not enough as feature availability depends on client library > versions and maybe compile flags .... > > As I said in another thread some time ago the best thing would be to > start from scratch with a cleaner design and new architecture. (Of > course taking experience from the current one) Right, it seems we should expose a proper OO structure. As in PDO_MySQL extends PDO .. I also never understood why we do "new PDO" while establishing a connection in the constructor. We should have made the API use a factory. regards, Lukas Kahwe Smith [email protected]