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]