Re: ONE database abstraction layer

> "Stig S. Bakken" wrote: > > > > Rewriting the "PEAR" class to C would IMHO not be foolish: it would save > > > > basically everyone using PEAR from parsing ~800 lines of code for each > > > > request, and it would speed up error handling and every other basic pear > > > > function. To me, that's a well-invested optimization (since everyone > > > > benefits from it). Agreed here. I would prefer a PEAR DB like interface with Metabase's rock-solid stability and DBMS independence... and XML schema, etc. In my view PEAR DB currently provides only a subset of metabase's capabilities _BUT_ I do think that PEAR DB's API is easier to use. Of course if someone wants to basically turn metabase into a php extension that uses a PEAR:DB style api, I will kiss their feet and use it in binarycloud in a _second_ if it works. The reason we use Metabase in binarycloud now is because it is feature complete. With the latest addition of clob and blob support, I view metabase as the best alternative. It has its quirks but I don't think PEAR DB, despite the nice API, is there. > > > way I see it PEAR-DB does not provide enough database independence. For I agree. > > > portabilty to applications. If you are going to port PEAR to C you > > > should rethink PEAR design to make it provide portabilty. > > > > > > Proposal: how about porting Metabase API instead? Think about this: Hell yes! preachin' to the choir brother! > > > - Metabase API already provides true portability to database > > > applications, so you would not need to crack your head doing what > > > Metabase already does. Yes. > > > - You could wrap PEAR DB classes around Metabase API so the current PEAR > > > DB users would not need to rewrite they applications. Nah, just take the PEAR api design wholesale and do it properly: Once. > > > - You could have a portable database API in PEAR right now using the > > > current Metabase PHP implementantion, and not in a year or whatever is > > > the time you would take to port PEAR DB to C. Yep. > > > - You could already benefit from Metabase database schema management > > > support features that no other database API offers, not in PHP nor any > > > other language. Which is a huge deal. We _rely_ on these capabilities in binarycloud. All entities are defined in XML and are then run through XSL to create metabase compatible schema files... which can then be loaded up on a database of your choosing. For obvious reasons that's extremely powerful and cool (and a perfect use of XML) and.. well.. necessary for my existence :) > > > - You could use Metabase driver conformance test script to verify if you > > > porting efforts of the drivers are being correctly implemented. Yep. > > > - Benefit from the already extensive documentation and tutorials that is > > > provided with Metabase. Which are 100% complete and 'production tested'.. i.e. I have had the shit hit the fan and needed some esoteric information about Metabase: it was there in the docs. Very, very good docs. > > > - Benefit from the toons of Metabase based programming components and > > > applications that have been developed. Yep, though I don't view an API change as a huge deal in this regard. I think you could provide some basic 'metabase backward compatibility' scripts that would allow old stuff to keep working, but I wouldn't mind an OOized api in any 'native' C version. > > > - Stop this silly implicit competition between database abstraction PHP > > > packages. There is much more to gain from cooperating than competing. > > > None of us if making money from it. All popular languages only have a > > > single database abstraction package (Perl-DBI, Java-JDBC, ODBC/ADO for > > > Windows languages, Python-DB, etc..). There is still a wrong idea in the > > > PHP community that there is no abstraction package in PHP. Yes. It's rediculous. Take the best ideas from each, use them. Get on with it. PEAR DB has a nice API Metabase is solid, tested, well documented and has fantastic unique features ADODB (um, despite its owner.. mini flame) is fast. Those things are good. Change the name to PHP Database Layer or something so noone can argue about ownership, give everyone credit, and enjoy having a single abstraction interface :) > > I'd very much like to see the features of Metabase in PEAR DB. If you > > want to do this, I'm all for it. Let's be done with the bickering, work > > together and have _one_ abstraction layer for PHP. Hear, hear. > > I suggest making a prototype called "MDB" providing PEAR DB-compatible > > wrappers around the Metabase API first. If this is successful, I think > > a C rewrite is due, the result being PEAR DB 2.0. IMHO the natural way > > of doing the C rewrite is copying the existing database extensions and > > rewrite them with a common PHP-level API. Yep. > Ok, I don't have much time right away because I am working full time on > the development of MetaL at least until the end of the year. > > That doesn't mean that other people could not start working on PEAR-DB > wrapper around Metabase. For instance, Lukas Smith was willing to have a > Metabase interface with a more OOP like syntax ($db->MetabaseFunction). > Maybe he would like to write wrapper class with PEAR-DB API and both > goals could be achieved. What do you think Lukas? Anyone who writes such a wrapper will have an immediate user base: binarycloud. I'll put that in the distro and start using it. I gleefully await a C rewrite :) I'm sure everyone working on binarycloud would agree. _alex