Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase

Tomas V.V.Cox <cox@idecnet.com> wrote in message news:01112015273205.19915@router.vulcanonet.com... > On Tuesday 20 November 2001 07:41, Manuel Lemos wrote: > > Hi Manuel, > > > I don't have the time or motivation to develop things for PEAR just > > because it is funny to cooperate. I am no longer a college student so > > I don't have plenty of free time to spare. What I do is because I > > need the things for my job. If I am not selling what I do, I don't > > have a problem with sharing. That is what I am doing with Metabase. > > That's the same here. At least me I'm here to develop stuff that I > later use in my work, so indirectly you and me are making money with > that as it helps our work to be more productive. > > > One thing is certain, I don't want to go where I am not wanted. If > > there is no interest in integrating Metabase in PEAR, fine. If not, I > > don't have a problem with that. From the silence of PEAR core > > developers, I am afraid there isn't much hope from their side to > > cooperate. At least I made an honest attempt to cooperate. > > It will be very nice to have a unique abstraction layer where all of us > contribute to. But in my opinion to impose MetaBase isn't they way to > go. PHPLib, ADODB, PEAR DB all are good developments with their > community and their developers, and trying to drop all of them with > Metabase is a crazy idea. > > 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/; 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. 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). > 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. -Magic Quotes murders our quoting, and what about magic quotes sybase which happens to be for interbase and sql server too! -Postgresql does not have an error number to return. And there is no pg_insert_id() either. -Interbase's API is missing an arm and a leg, and whether it is the left or right arm missing is not documented anywhere. -All extensions should support blobs like Oracle, with a fetch mode that makes "SELECT blob FROM table" transparent with no special coding. 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... John PS: the history of windows shows it's ok to have multiple abstraction layers: ODBC, RDO, DAO, ADO, ADO+, JDBC, Delphi's db classes, VB's data controls, provided there is progress.