Re: Re: [metabase-dev] MDB news

Hello, On 09/05/2002 07:59 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.

That is ridiculous. I started Metabase in late 1998. I released it early 2000. It took a little over 1 year before I decided it was ready for release with 6 drivers. Most drivers were ready very early. The reason why I waited a year was so I could give myself sometime to learn and reflect about the diferences between each database so I could be certain that once I released it to the public I would not be able to change the API in a backwards incompatible way. I am glad I did it as life taught me that important ideas need some time to mature.

But our code is currently available via CVS - a release is just a fixed (hopefully working) point in the flow of cvs, which at any random point

You are not getting the point. I waited because I was not sure if I would need to change the API in a way that would break the applications of users that relied on it. The problem is that some time the first ideas for solutions of certain problems are not the best and you really need to rethink them to fit in the limitations and possibilities of many different databases.

in time could have broken code in it. Metabase development seems to use a different method of development (at least I couldn't find a cvs for it), it seems you develop in private and release alphas, betas, and releases. That's cool, I'm not trying to argue that one method is better than the other all I'm trying to do is point out that they are different. Our code is 'released' every day and available for the 'public' to use if they are fool hardy enough to use anything directly out of CVS.

It is pointless for me to provide access to a CVS server for people to hack it. I use Metabase in production servers often using features that I did not have the time to document. I absolutely need to keep control of the changes that are integrated because if somebody enters an hack that was not verified while I am adding something else that is ready for use in production, chances is that somebody else's hack will screw my applications in production. That is something that can happen with the "everybody can hack any time" development model of PEAR. I prefer to use a controlled development model pretty much like Linux itself because I can personally assure that no bogus code is hacked in. Meanwhile, the beta version of Metabase changed files is available here: http://groups.yahoo.com/group/metabase-dev/files/beta/ I can mirror my own CVS repository files, but not everybody can use them.

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.

That's not what I meant - what I mean is that is may take these 3 hackers a long time since we may or may not be interested or have time to port the metabase drivers other than those databases we use.

That is an inadquate posture to develop a database independent package. The problem is that once you start adding features and do not test them in add databases, you may risk to realize that the implementation is not feasible in the other databases that you did not know and you need to rethink the API breaking backwards compatibility. The users will hate you for that.

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. 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. I come here and bother to share my real world experience but still I have to put up with unexperienced people claiming that the cosmetic fixes, which is mostly what pearification means, are necessary, when all we see is that those that claim pearification as necessary will not do a damn thing to help. Basically, I proved to be right when I claimed they were just stalling. What I got was just silly accusations that I was being paranoid. So there you have it. At this pace the Metabase x PEAR-DB merger will not happen anytime soon.

I'm not sure I understand what you mean with all this - are you saying that MDB is not necessary and we should just import Metabase into PEAR as is and then only gradually 'pearify' it?

Yes, that would have allowed to have more drivers, if not all of them, ported and tested now. Also, notice that while you pearify it by hand, you tend to change things that worked to use some other functions of techiniques that you prefer but in the way things stop working for something that you overlooked or did not understand why it was that particular way originally. It would be much better if you did not bother to change something that worked.

Porting just to MySQL or PostgreSQL will not assure that the portability assumptions were right, despite Metabase original drivers were proved to be as portable as they could be. The problem is that Lukas keep making changes before other drivers are ported and such changes eventually break portability. The question is, when will people ever trust my experience and start listening? Maybe when they reach maturity and stop the childish anti-Manuel-Lemos work atitude.

I don't have any anti-Manuel attitude - it was your persuasive arguments that changed my opinion on some kind of PEAR Metabase merger. The problem we end up with is this; while probably the majority of the code in MDB line by line code is yours, stolen out of Metabase, your comments are easy to perceive as those of an outsider, since you have not been involved in the commit to commit developement of MDB (whereas you are probably more 'inside' MDB than any of us). It's also difficult to know

That is not true. I am subscribed to the PEAR CVS list and I follow in particular all the commits that are done on MDB. I can tell you that several times I could not understand WTF certain things are added or changed because the CVS log comments reveal that very likely you got wrong what the original code was meant for and why it was done that way.

what to do with your comments when then basically you seem to be saying that what we are doing is all wrong, that we don't respect you or trust your experience. If I didn't have any respect for you I wouldn't steal your code or bother replying to your mails.

If you do not understand a comment from me, ask for further explanation. If you go on ignoring the comment, chances are that you will realized what I was commenting much later.

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.

The metabase driver test is great for testing metabase - however in MDB metabase api is provided by a wrapper, so in the event it shows up a bug there is an extra layer to investigate. What I want is the same tests

Metabase driver test conformance script is meant for verifying functionality that does not conform to what is documented. If you find a problem chances are that it isn't in Metabase wrapper. Even if it is, you still have to fix that because otherwise you will discourage Metabase users to start using MDB.

directly accessing the MDB api - but (if I have understood) your thesis is that MDB is wrong and Metabase should be imported as is, then you are right I am wasting my time.

At least it should be considered as a low priority activity because there are certainly more important things to do.

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.

Yes, but do you want us to listen and meekly and blindly do whatever you tell us ;-) Realistically! I've got experience too and a viewpoint and you can't simply trump them because you have more.

That is not what I said or meant. What I meant is that I shared my experience and it was ignored. Now you can verify that if you have listened to me before, among other things, MDB would not be so delayed. It is like me telling to jump off a bridge or else you may die or drown and that is not a good thing, still you jump off a bridge just because you decide to have a different viewpoint. Then you realize that it happened what I told you and if you have listened to me before you could have avoided the troubles. -- Regards, Manuel Lemos