Re: PDO Ground Rules

From: Date: Tue, 15 Feb 2005 09:30:32 +0000
Subject: Re: PDO Ground Rules
References: 1 2 3  Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-2000@lists.php.net to get a copy of this message
Lester Caine wrote:
But for PDO to replace an existing driver it needs hooks for things other than just the data connection. We have established (as I understand it) that it will not provide generic facilities such as 'SQL mangling' so that SQL specific to the server engine will be required to access such information as list of tables, schemas, databases, etc., but some generic means of accessing an engines services interface will be necessary before the need to run an existing native driver in parallel with PDO can be removed? Backup/restore, starting/stopping, user management - thing on some engines that are not managed via SQL at all, or require connections to the database to be closed before they can be actioned. THAT is what I am having difficulty 'picturing' in the way that PDO is currently structured. I expect to be able to access the database server without necessarily opening a database. That may be possible by providing simply a driver and server name in the dsn, but in my mind I need something more than get and setAttribute to control things. Once I can see HOW to remove the native driver from my code I will not have a problem, but at present both are required, so the incentive to switch is not so strong. That is what I have been trying to get across rather unsuccessfully. SQL Mangling *IS* another layer, but there are still functions that while they can sometimes be handled via SQL Queries, on the whole they need direct server access.
In reality very few applications require all the above mentioned features. It seems that these applications will have to wait a bit before they can migrade. We also discussed this topic and kicked around ideas like being able to "cast" pdo ressources to native database ressources in order to be able to use the old extensions for the not yet supported features. In the end this idea was dropped since it didnt seem feasible to the core developers. Anyways, we did actually put alot of thought into PDO. And it would really help the discussion if you could shift your assumptions in this regard a bit to a more positive tone (well you definately have improved from the very rude initial tone .. so you are going in the right direction). Thats not to say that there may still be good ideas that could be incorporated into PDO and that there are no API kinks (hey I keep coming back with issues in the prepare()/bindParam() method calls). So there is nothing to be said against positive criticism. regards, Lukas

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