Re: Adoption of Metabase

Manuel Lemos wrote: > > Hello, > > Peter Bowyer wrote: > > > > Hello, > > > > At 11:09 PM 11/18/01 -0200, you wrote: > > > > OK, let me stick my neck out :-) > > > > Metabase was written for PHP3, and therefore if rewritten for PHP4 w Zend > > > > Engine 2 would probably see some significant speed increases. Manuel > > > > > >AFAIK Metabase is not affected noticeably in performance due being able > > >to also run with PHP 3. > > > > From what I've read, I'm surprised about that, but am willing to be corrected. > > When you assign a variable with the value of another object variable, > the object is copied, thus you are no longer manipulating the same > object Metabase avoids this by storing object of the driver classes in a > global array and returns an integer that is the index of that object in > that array. All Metabase API calls dereference this object index value. > Still it is not an operation that adds significant overhead, because the > API calls do much more than that. > > > > > > already knows my views on the function naming, and I would really like to > > > > see it have an API like PEAR-DB - not a wrapper (more overhead) but truly > > > > rewritten, to the PEAR standards. > > > > > >Shifting Metabase API to something else would meant droping support to > > >all the existing Metabase applications. The PEAR-DB wrapper was more to > > >keep the PEAR-DB API to please people that are already using PEAR-DB. > > > > But we don't want to have an API that in 2 years time we will look back and > > wish we had changed - by which time there will be many more people using > > it, and so it cannot be changed. If we changed the API we could always > > write a Metabase wrapper for it :-) > > I don't think there is much need to change PEAR-DB API, except for > adding what is missing. I am open to incorporating features from Metabase that are missing from PEAR DB. Metabase seems to have solid implementations for the databases it supports (unlike DB, where many are left behind, such as sybase and odbc). But I think an architecture redesign will be necessary to provide enough modularity to provide the flexibility required without too much request startup overhead. In particular I would like to use more aggregated objects for a plug-in architecture that would allow people to load the code for feature sets only when they are needed (like you mentioned on the metabase list about separating the data definition queries into a separate "driver file"). Also, I'd like to explore the possibilities provided by Andrei's new overloading extension. I agree that it's time to start consolidating the most popular database abstraction layers out there. I think the redesign I outline above should be able to provide users with both runtime performance ala. ADODB _and_ portability ala Metabase. However, I'm in the middle of selling my house, refurnishing, moving etc. now so I don't know how often I'll be able to catch up on my mail. - Stig