Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:14865 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26699 invoked by uid 1010); 12 Feb 2005 09:56:59 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 26684 invoked by uid 1007); 12 Feb 2005 09:56:58 -0000 Message-ID: <20050212095658.26683.qmail@lists.php.net> To: internals@lists.php.net Date: Sat, 12 Feb 2005 10:01:44 +0000 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en, en-us MIME-Version: 1.0 References: <4e89b4260502111655215a94e8@mail.gmail.com> <20050212074627.64626.qmail@lists.php.net> <4e89b426050212001234271b83@mail.gmail.com> <20050212090244.59428.qmail@lists.php.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 81.138.11.136 Subject: Re: [PHP-DEV] Re: Please test PDO From: lester@lsces.co.uk (Lester Caine) Derick Rethans wrote: > 1. ADOdb has *nothing* to do with the PHP project It would not exist without it. No reason why it could not be part. > 2. Some people don't need bloated libraries as ADOdb and still want to > have one single unified interface to databases - THAT is what PDO is > for: raw access. Yes ADOdb is large, and that is part of the point. The core needs help from PHP to become lean, and then the extensions are just bolt-ons to a lean core. PDO should be that core, but I'm not seeing that at the moment. I'm seeing 'BDE' all over again. An attempt at a flat world view of databases that eventually died because it lost all abbility to also surface the strengths of the engines it was accessing. > Again, ADOdb is a PHP USERLAND solution, PDO is not. PDO is C, PDO is no > bloated OO, PDO is fast. ADOdb has a C accelerator that would benefit from the same sort of work that has been put into PDO - it's an existing project. > Feel free, I don't care what you want to use - if you don't care about > PDO, fine with me, good luck with ADOdb. My particular problem is mapping the SQL scripts between engines. That requires access to functions that PDO - I now learn - is not planned to provide. So *PLEASE* remember telling us what something will NOT do is as important as pushing what it does. Wez has already said what he does not plan to do with PDO - and that causes problems switching the next layer applications TO it. So we still need to plug that hole - PDO will not do it :( -- Lester Caine ----------------------------- L.S.Caine Electronic Services