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

Hello, Paul Cooper wrote: > > 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. If you are going to develop database specific applications you have to be aware of the differences. Also, PEAR-DB does not wrap around everything that you can use from each database. That is why it is a bit pointless to use an incomplete abstraction layer, being that PEAR-DB, ODBC, etc..., to develop database specific applications, especially when you can use the native API to take the most of the database specific features, furthermore without the overhead of each database. Want an example? How are you going to handle blobs or stored procedures with PEAR-DB? You don't, you will always have to resort to the native client API. > 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 That is not accurate. If you don't want to do portable database programming, you don't need to use everything of Metabase. > 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). You do not have to use Metabase schema manager to install your database schema. Even if you do, you can add to it what is missing over what it supported. > > - 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 - Competition is good for consumers of commercial products. There is no commercial product here. > 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 I don't have time for more silly discussions. A lot of people that wanted to include their stuff in PEAR, simply gave up because they do not agree with those standards, as they are basically like Jon Parise explained an adapted version of Horde standards. That is a silly discussion because it prevents people from contributing. Anyway, I did not develop Metabase to contribute to PEAR. Metabase was started more than a year before PEAR begun. So, I don't want to enter the discussions of standards of PEAR. My point here is that there a lot that the PHP community loose for not having just one officially sanctioned abstraction package for developing database independent applications. > 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. I don't have the time. My point is that if Stig is willing to spend a year or whatever it takes to port PEAR-DB to C, why not porting Metabase API instead and benefit from all those points that I mentioned? > 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. I'm sure you have not thoroughly thought about what you said. If there is more than one popular database abstraction package for PHP, it means that the community that is using them is split. So all those utilities and database components can't interchangeably be used by everybody because not everybody uses the same database abstraction package. This is why competition is bad in this case. Regards, Manuel Lemos