Hi Lester, On 8/3/07, Lester Caine <[EMAIL PROTECTED]> wrote:
> Sorry Pierre I have to disagree there. Most flexible projects are built on > ADOdb, and while you CAN use PDO as an alternative driver, for the best > performance the raw drivers are preferable. I don't see anything to replace > the SQL handling that ADOdb provides although the ADOdbLite does work well if > you do not want a fully featured interface and can do without some of the more > advanced SQL code. Sorry, I was not clear enough. I did not say that PDO is perfect or can replace MDB2 or ADODb, it is not its goal. > Being able to build a project for ANY database is nice to > have but requires you manage the SQL as well as the data, and if you are not > building a generic project then you don't need a generic driver. A common base is already a (very) good start. We obviously need more and it is unclear how far PHP should go (talking about internals only here). > I keep being told that the PDO drivers can be extended to include all of the > things already available in the native driver, but the second you do that they > become incompatible, so in addition to the PDO driver you need to also run the > native driver simply to provide the areas NOT covered by PDO. We need a > generic framework that addresses the real problems not one that creates an > artificial lowest common denominator strangle hold :( PDO could evolve into > that, but not with it's current restrictions. And what do you suggest to improve this situation? One of my suggestions is to have more DB developers (as in DB internals, if I can say so :) involved. Oracle and IBM (to name the largest and most active) understood that and actively participate. I'm not saying that you do nothing, but I'm not sure that complaining about the bad state of pdo_firebird is really helpful. Cheers, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
