Re: Re: [metabase-dev] MDB news

Hello, On 09/05/2002 06:32 PM, Lukas Smith wrote:

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 :-)

Yes, I will be repeating myself, but please understand that while you ignore how other databases that you don't are different from those that you tried, chances are than the new features that you add may not work with other databases and that compromises the true portability reputation. You don't have to do it all by yourself, but at least wait until you have all the core drivers ported and tested before you can add safely any new features because then you will be able to have people supporting such features and demonstrating that they work well with all drivers.

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.

I wish you did not make such misleading statements. The truth is that the speedup was achieved with the bulk data fetching functions that you contributed to Metabase before you started MDB and with a direct to driver object API calls that were also introduced in Metabase before. If the outcome of this discussion is going to be that MDB is being assumed as competitor package of Metabase, I am not interested to participate in the discussion nor interested to participate further in MDB development in any form even if it is just by providing input on how things should be done.

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.

Servers crash when they exhaust memory. It may not be the use of PEAR base class when it is not needed that will make the difference, but certainly that spirit of ignoring all the abuses of memory when you need to setup a server farm where your budged may be drastically reduced if you pay more attention to memory waste.

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.

XML itself should not be used for that purpose. The solution is not to write an optimized parser but rather use a file format that allows for streaming of data. XML is not suitable for data streaming.

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?

I don't recall every seeing such estimates. I just recall you saying that porting drivers would take a couple of days each.

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.

I am not questioning your reasons for the developments, but rather the priorities order.

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.

Opinions on style are not a thing everybody agrees.

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.

You are missing my point. Stability is not something that you decide. That is something the users experience. If you say something is stable and users have an experience that does not match what you say, it is irrelevant what you put on the project page.

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

I am not painting any picture that does not match the reality. The truth is that I warned from the beginning that if you keep wasting your time like a "prima donna" making cosmetic fixes to the code that really do not add any absolutely needed features, obviously you will take much longer to port the drivers and make them useful to anybody. You could have made the cosmetic fixes later if ever at all, but since you decided to not listen to what I advised, the fact is that you only have 2 drivers of the 7 drivers of Metabase, not to mention of a few that may be added soon. I can't be bothered to repeat myself, so you draw your own conclusions on why MDB is still very late with no clear picture of when it will be usable for all those databases.

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).

I did not say that MDB is just adding bugs. What I said is that like I predicted a long time ago, while you would be making cosmetic fixes you would inadvertedly introduce bugs where none existed. The MDB CVS logs are there to not let me lie about this. Even with my warnings, you insisted on doing it. Of course that contributed to make MDB take longer than just the "couple of days" that you naively supposed that it would take. One thing you can be sure, if I bothered to advised against certain things, that is because I am truthfully trying to help you to reach effective goals much sooner than you would otherwise. If that was not clear for you before, I hope it is clear by now. Anyway, if no matter how much I bother to express clearly the reasoning for my advices, you will still go against what advice, put yourself in my position and ask: why should I bother to continue to advice if people do not listen? Honestly I prefer that people say, we don't care what Manuel Lemos says because we are not interested in his experience. At least that would save me from spending a lot of time writing these lengthy e-mails when I have so many important things to do. -- Regards, Manuel Lemos