Re: Re: ONE database abstraction layer

Hello, Shannon Weyrick wrote: > > > 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. > > > > 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? > > > > SiteManager (www.roadsend.com/siteManager) also has an interest in getting > Metabase "ported" to PEAR. While we looked at using Metabase exclusively for > the database extraction layer before 2.2 stable was released (on a tip from > alex@bc :), in the end it was the API that didn't fit into the SiteManager > framework, and so we went with PEAR. The more OOP like syntax that you > mention above is exactly what I was looking for before. Although this is pretty much irrelevant to discuss right now, the current Metabase API always has been Object Oriented. In fact the $database parameter is a reference to an object and the function names directly map to functions of the driver classes and the Metabase prefix acts as a namespace identifier. What most people mean with an "OOP like syntax" is a C++ plus like syntax hopefully to type less characters, which has nothing to do whether the API is OOP like or not. > Now that SiteManager uses PEAR, however, I'm obligated to keep the same API > so as not to break backward compatiblity with SiteManager based sites. Thus a > PEAR wrapper around metabase would be beneficial - but what are the > performance issues, I wonder? It seems instead of SiteManager->PEAR->db I > would move to SiteManager->PEAR->Metabase->db. Performance is one of the key > issues of our current development line. > > Of course a C port makes all of that moot.... > > And while it's clear that many could benefit from such a port, perhaps the > hardest part would be finding enough people with the time to work on it.... I am more concerned with the piles of features that Metabase offers and PEAR-DB doesn't, than with any claimed performance overhead. If all works well as proposed and Metabase API gets ported to C, you do not have to worry whether there will be performance issues or not. What matters for now, is that once a PEAR-DB wrapper is implemented around Metabase you may start benefiting from Metabase features right away without having to wait months or years until it gets ported to C. Regards, Manuel Lemos