Re: Adoption of Metabase (was Re: [PEAR-DEV] Re: Comparing ADODB with PEAR DB, Metabase andNative MySQL)

On Sat, 2001-11-17 at 16:54, Manuel Lemos wrote: > There is no great point on using database abstractions unless you want > to develop database independent applications by using the same API. The > way I see it PEAR-DB does not provide enough database independence. For > many things you still have to resort to database specific solutions, so > your applications will still not be portable. If they are still not > portable using PEAR, you may as well not use PEAR or any other database > abstraction package and save yourself of the overhead of using any of > such packages. So, database abstraction package should provide true > portabilty to applications. If you are going to port PEAR to C you > should rethink PEAR design to make it provide portabilty. Well I'm just a lowly developer, I just use PEAR db, I didn't develop it so I could be wrong about this but .... the reason I use PEAR db isn't to try and build database independent applications - it's simply to make my life easier so I only have to remember/learn one api, rather than keep reminding myself of the subtle differences of mysql_query, pg_exec, etc. I think of PEAR db as a unified api rather than an abstraction layer - that's why it'd would be cool if it were ported to C/C++ php extension. I last looked at metabase a the beginning of the year and the reason I chose PEAR db over Metabase is that it appeared* to me that I had to either use metabase totally or not at all - meaning either I had to accept it's abstraction of things or not use it. In the last few projects I've needed to use some 'unportable' aspects of postgres which I couldn't get to through metabase (e.g. constraints, foreign keys, f keys over multiple columns, cascading deletes / updates / restriction, etc etc). *this is just how things are I as saw them - I not proposing this as a statement of fact. I'll look again at metabase if I'm wrong as there were many things I liked. [snip impressive list of features] > > - 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. I wish some people developing open source software would repeat the mantra 'Competition is a Good Thing(tm)'. PEAR db and metabase compete - so what? If you want metabase in pear then you can get the coding standards and make sure your code adhere to it (or simply start a thread moaning about the coding standards, which seems to be the other way to try to get code into PEAR). If you want Metabase rewritten in C as a php extension, then feel free. If you want to write a PEAR db wrapper for metabase so existing apps can easily switch then no one is stopping you - combine that with a fast C written metabase and you'd have a killer feature set IMO. One of the great things about the PHP community is that we aren't trapped into one db abstraction / api that we don't like - we have many to choose from to suit our preferences and needs (including fast direct access). Anyone who doesn't know about the many db abstractions (or at least one) hasn't learned to use google / freshmeat / etc yet. JMO, Paul > Well, this is what I meant to talk to you in San Diego O'Reilly Open > Source Conference and in Frankfurt, but for whatever reasons you could > not attend. Anyway, I am giving the hand for cooperation. It is up to > you to decide if you would like to take this chance for the benefit of > the whole PHP community. > > Regards, > Manuel Lemos > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, e-mail: pear-dev-unsubscribe@lists.php.net > For additional commands, e-mail: pear-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net