RE: [PEAR-DEV] Re: [metabase-dev] MDB news

> From: Manuel Lemos [mailto:mlemos@acm.org] > Sent: Thursday, September 05, 2002 10:37 PM > On 09/04/2002 01:04 PM, Paul Cooper wrote: > >>I think you should first port all drivers before you add new features to > >> parts of the package that depend on features of the abstaction layer > >>that need to be added or improved. > > > > > > This would be nice in a perfect world, but given the current make up MDB > > hackers this would mean that you could expect a release sometime in > > 2005. Lukas and Christian seem to use mysql and I use mainly pgsql, > > mysql a little, and interbase even less. > <snip> > > Since you hardly need to add any database related features to the > drivers, your claim that it would take several people a long time to > port all the drivers is absurd. Yeah porting a driver does not take all that long. But someone still needs to do it. And I have said that I can't also port all drivers. I never said that I will take responsibility to write MDB alone. With the 1.0 release I want to give a message to the community that now is the time :-) Also remember that MDB is much larger than any of the DB abstraction layers, because it simply offers more features than any of them (being a superset of PEAR DB and Metabase). So yes MDB needs community help (which I have allready gotten in the form of Christian, Paul and Brent). > As a matter of fact, I always told you to leave the cosmetic fixes that > PEAR people insist that is necessary to a later phase. That was used as > an excuse by Metabase detractors to stall the merge. The very simple benchmarks I have run show that MDB is considerably faster than Metabase. I know the benchmarks are simple, but there is no reason to believe that MDB would be slower in more complex usage situations than Metabase. One thing that may be true is that MDB consumes more memory. And this could become a problem as your application scales. But then again faster processing also means faster completed request's which also reduces memory consumption. The new parser was introduced because the old one was fairly slow. I know that XML is not the best form to dump lots of data. But we actually got the memory consumption when parsing a 7MB xml schema down from 600MB to 20MB iirc. > Since people are now willing to accept Smarty without requiring any > pearification, there is even no longer that argument of stalling > Metabase x PEAR merger because after all I proved to be right from the > beginning that the pearification process would be needlessly lengthy and > error prone because whoever does it is always at risk of introducing > bugs where none existed. Well the estimates given when I started were 1 year. That would give me until next February. So I am ahead of schedule. How long did porting of the pgsql driver take for you Paul? <snip> > > > An interbase driver is on my todo list, but only after I've ported (and > > added to) the metabase testing script to PHPUnit (because the metabase > > script has to go through the metabase_wrapper it involves too many > > layers, we need testing that directly manipulates the MDB api, but it is > > a starting point to copy). > > That is yet another silly needless thing. Metabase driver test > conformance script proves that Metabase is portable as it should be. It > doesn't matter what is underlying it, being that the original Metabase > drivers or the ported to MDB. So, porting the tests to PHPUnit is yet > another waste of time. > Well your testing suite is very useful if you have nothing else. But the problem with the testing suite is that its really hard to track errors in order to fix them. It was always very time consuming to look through the code and add output statements etc. The code that Paul wrote is very easy to navigate and I think this will make fixing bugs in drivers much easier. Also the code looks to be very easy to extend and that is also a key feature. > I don't care go ahead, your 2005 projection is probably right. You are > learning at your expense. By the end of it, you realize that you hardly > added enough to justify the time you spend redoing things. > > > > Those of us who actually use MDB need a release x.0 target which we can > > then branch into a devel x.1 version. You can argue about what the value > > of x should be (e.g. 0.5, 0.7, 1) but I think we something 'firm' and > > bug tested so that; > > If you did not bother to make so many cosmetic changes, the chances of > still having bugs would have been gone. It is not that I haven't warned > about that before. > > > > a) We can use in client projects with out having to worry about CVS > > bleed, > > > > b) we have a fixed target for bug reports and fixes. > > > > c) Early adopters can test and play and hopefully get exited enough to > > write the driver they need. > > That is wishful thinking. It may happen, but chances are that it won't. > Things are looking good from my perspective. Christian and Paul are both very active. Others have said that they will join. If only the MDB_frontend project that expands MDB beyond what Metabase does in terms of helping users manager their schema's. > >>That has always been a problem with PEAR-DB API. Early versions were > >>released to the public with features that were not tested in all > >>databases so they had to be redone, patched or have ugly optional > >>arguments to assure compatibility with something that was badly designed. > > > > > > I think we should combat this by just being ruthless about backwards > > compatability until the API is stable and we have a good range of > > drivers (i.e. change the api as needed until we have all the drivers). I > > That is the unprofessional way of doing it. The reason is simple. While > you do it, some people will try it and get burned because you keep > changing things and they will not bother to try it later because once > burned, twice shy. > Well I think that the amount of to be expected API changes are pretty small. Even for the manager. But they might happen more frequently than in Metabase until we have more drivers and the new features and structural changes that the manager needs are implemented. I think this fall with MDB 1.1 we should have reached a similar level of API stability. > > think you have a point if you argue that we should not be having a 1.0 > > release - maybe a 1.0 should be reserved for MDB with stable API and > > most drivers, and we should be releasing 0.5 or something. But in the > > end the numbering is just arbitrary so we just have to agree a roadmap. > > Version numbers are irrelevant because they are misleading. I never use > 0.x 1.x or whatever. I use YYYY.MM.DD . That way people will know how > old things really are and don't make assumptions about stability. Well that information can easily be tracked on the project homepage. > Anyway, that is just me. I am not that way by accident or because I am > just being stubborn to not admit anything somebody told otherwise. I am > that way because my life experience told me that is more convenient. You > may either learn from the experience that I am sharing or just remain > stubborn against what I say and soon or later deal with the consequences > of not listening from those that share their experience. > Well I think you are painting the picture for MDB alot darker than it really is. I really appreciate all the help you have given me in the development by answering my questions. I don't expect you to write any code for MDB directly. MDB benefits from your development in Metabase because I port all interesting things to MDB (it doesn't take all that long and it means that I take a close look at your code which also helped me find little bugs in your code, so MDB is not just adding bugs but also helping in fixing bugs). Regards, Lukas