John Lim wrote: Hi John,
> > > > > The only exit I see of the multi abstraction layers problems is trying > > to join all those communities and start a new development from the > > ground. The code is almost all written so only need to glue it to meet > > the specs of the new resultant layer. Then each team could provide > > their own wrappers to make things easy to their users. That's IMO a > > cooperative behaviour. > > > > Tomas V.V.Cox > > Hi Tomas, Manuel, everyone, > > I think that different programmers have different needs. > Metabase's goal is 100% DB portability. PEAR DB builds on the > PEAR classes to give a solid set of classes. ADODB is aimed > at converting the heathen ASP'ers to the "one true religion". > I also know of a PHP DBI class also from people who still need > the $perl~= /fix/; All the things you say here could be the features of a new abstraction layer done by a high experimented team. The point is to relax a little our obsessions. > Each designer has a different point of view, like Tomas has > written a really excellent oci8 "select limit" emulation, but looking > at the code, it's so complicated that i decided not to incorporate it > in ADODB because I value simplicity. I know Tomas' code works > in theory, and its really impressive that you even considered UNIONs, > Tomas, but I just like "simple" code that I can keep in my head. Thanks for the kind words :-). I know it's a little bit obscure cause I needed to implement part of a SQL parser, but with more resources in a supposed union we could develop a real SQL parser and in the case of the row limit for Oracle the code needed will be reduced to two method calls. > I think some standardization in terms of API is good, but I don't > think most people care. Newcomers to programming will want to use > something easy and "standard" - is PEAR DB already the standard? > Windows programmers would want to use something familar. I already > have a prototype PEAR DB api wrapper for ADODB , and ADODB has > support for PEAR Error() also, but the people who like ADODB > generally are not that interested (at the moment). They don't want automatic error handling? Uff, I couldn't live with it ;) > > to join all those communities and start a new development from the > > ground. The code is almost all written so only need to glue it to meet > > the specs of the new resultant layer. > > Actually the common code is already available: it is the > database extension API's. But most of the problems are > in the database extension APIs also, and our work is fixing > their mistakes. > > Examples: > -Oracle ocifetchinto() returns OCI_ASSOC arrays in uppercase, > when everyone else is using lowercase. >From PEAR we requested the native C PHP function to change the case of the key of the resultant array and the waste of exec time is almost null. This function will be avaible in 4.1 (I guess) and in the PEAR DB that will come with it (I hope). > -Magic Quotes murders our quoting, and what about magic quotes > sybase which happens to be for interbase and sql server too! Yeah, magic_quotes_* are evil and they should be off by default. Anyone with enought karma can do that? :-P > -Postgresql does not have an error number to return. And there is > no pg_insert_id() either. The error numbers is a PHP API problem or Postgres API one? PHP would suck a lot if that is supported but not used, knowing that the Postgres guys change the error messages in each release. About the pg_insert_id(), Postgres have native support for sequences IMO the real way to do that kind of things. > -Interbase's API is missing an arm and a leg, and whether it is > the left or right arm missing is not documented anywhere. That's true. I used Interbase time ago and was very robust, also now is Open Source and is a backend with the features of Postgres and the speed of MySQL. The lack of a good PHP support is limiting it's use for sure. Well, a DB with some backdoors but they are being closed ;). > -All extensions should support blobs like Oracle, with a fetch mode > that makes "SELECT blob FROM table" transparent with no special > coding. I don't use them, can't say anything on that. > If we fixed these problems and more, we could talk about having > a unified API. Otherwise for the Oracle OCI_ASSOC, I would prefer > not to change it for speed, Manuel would want to provide an emulation > layer, i would object because it's slow, etc... > That's solved (see above) :-) Tomas V.V.Cox -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
