Re: [binarycloud-dev] Re: [PEAR-DEV] Re: [binarycloud-dev] Re: [PEAR-DEV] Re: [metabase-dev] RE: [PEAR-DEV] New Metabase Aniversary release

> a) Don't really need to port it to another database that often > b) Don't want to port it by using an abstraction layer, you'll want > to design and optimize your tables differently on Oracle then you > will on MySQL. ok I'll go back to my cave and code all my applications in C++ and compile them into apache modules. hey, they would be fast when I was done :) actually, both of the things you said are for me untrue. I use the same schemas in oracle and mysql because metabase's XML schema capabilities allow me to. That's a good thing. Also, I certainly do have the need to be database independent because my clients do make different technology decisions. I may well be porting an application from oracle to DB2 shortly, and because of metabase I will have very, very little trouble doing that. as of binarycloud r2 that process will be even less trouble. > DB abstraction and SQL abstraction do have there uses, no doubt (for > example, applications that you give to other people), but they are > certainly not "core components to any application." How many PHP application packages _don't_ use a database? I can tell you: less than 5%. That's 99% of PHP's user base: people building applications that talk to databases. If all those applications used a common abstraction layer, the PHP community would benefit a great deal, as users could deploy applications on MySQL, Oracle, DB2, whatever. >> Remember, PEAR ist not Midgard. PEAR is no application framework. >> It's a pool of classes that follow coding standards. >> > Its more than that, its a unified/organized set of classes that > follow coding standards. Define "unified" "organized" Classes in folders with names that make sense? Or classes that have underlying system design? > I do agree. I'm not saying "down with metabase", i doubt that > manuel will be folding phpclasses.upperdesign.com anytime soon, and > saying "PEAR is soooo great, ohhh my fucking god!" he he. Indeed no. > I think we should leave PEAR::DB as the only database backend, with > a unified API (perhaps extended now with the inclusion of metabase). > And then let users go to phpclasses if they want metabase, its not > like its really that hard. the entire point is to get this all cleaned up in the community. 90% of people agree on these points: -metabase is mature -metabase is the most feature-rich -PEAR's API is cleaner given that does it not make sense to take the good from each and create something that is in the end, better? If sounds like you're happy to have people coding to the native database functions in PHP for their applications? In the opensource world, that doesn't work. _alex