Re: general questions

Hello, Joao Prado Maia wrote: > > Well obviously nobody wants functionality to break. Neither metabase nor > > Pear DB. But if we want this thing to be good I do not want to slow > > things down to much by legacy support. So what I will try to do is > > provide wrappers for both Metabase and Pear DB. > > > > What type of "wrappers" are we talking here ? Are they going to be just > another class on top of the existing Metabase and PEAR::DB APIs ? Or are > we talking about re-writing the whole PEAR::DB to enable the features > available on Metabase ? > > I find the idea of Classes on top of Classes, which are on top of other > classes and so on kind of scary. PEAR::DB is rated 'slow' on some > benchmarks like it is today because of all the setup time it needs to do > to create the class definitions of all the needed stuff. Isn't this going > to slow things down even more ? > > I understand that the original proposal of Manuel Lemos was to provide > PEAR::DB with the features of Metabase as soon as possible, but creating > something that is flawed by nature cannot be a good goal. We should think > about the speed issues before starting to work on anything here. What I proposed is something to be done in multiple phases. The first would be to wrap Metabase API inside a PEAR-DB driver. Eventually this could evolve in a later phase into something that wraps with Metabase drivers directly because Metabase was structured in such way that it allows to have different APIs to the same core, which are the driver classes. > In any case, I might be able to help if we keep the objectives clear. In > my personal opinion, I rather have the current PEAR::DB intact when > possible and add the Metabase features. We need to test things before we come to conclusions. Keep in mind that Metabase offers much more power to database programmers. It would be bad to squeeze Metabase API just to fit in the limitations of PEAR-DB API. For now, I think it is better that just one person concentrates on that and then presents his results when he is done. You know the saying: "A camel is a horse designed by a commitee". :-) I trust that Lukas is a capable person for this job. So, lets let him be in charge of it. Regards, Manuel Lemos