Re: [PDO] Asynchronous requests

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.

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

johannes