Re: Re: [metabase-dev] MDB news (http://pear.php.net/package-info.php?package=MDB)

Hello, On 09/06/2002 05:58 AM, Lukas Smith wrote:

Manuel you are right. I may end up having to make some serious decisions of ditching features down the road. I was in a difficult situation of having to pelase both the Metabase and the PEAR DB userbase. I am trying to win both sides for MDB. People don't like to give up features if they don't know what they will gian in return.

Yes, actually that was my initial proposal, please "greeks and trojan" in a way that they do not need to change their applications to use MDB.

So I guess what I did is give both sides all the features they are used to. Since especially PEAR DB does not abstract as much this may end up being a problem once we actually have to work out compatiblity to more RDBMS. I allready had to make some changes to the code for PostGreSQL support (I did not have to remove features however or change the API). For all intents and purposes MDB 1.0 should be considered to be a more public development version. If you do not want to ever have to look at the MDB code for even one second then this release is probably not for you. This release should be viewed as a pre Final version in order for people to prepare moving over and to contribute drivers.

That is not what I meant. I don't have the time to study the changes in depth to understand what they are meant for. I keep an eye on the CVS log but actually providing valuable feedback when I think I can takes me time that I would to steal from activities that I need to make a living like anybody else. If I bother to spend time providing such feedback just to realize that it is mostly ignored, it does not make much sense to spend the time doing it.

Because yes you are right, we might run into trouble with other RDBMS down the road. Also keep in mind MDB is not here to compete with Metabase, but more to expose Metabase to a new userbase and to ready it for future development. Again I thank you for your insights and your persistance in making your experience available to the community.

Actually sometimes I think that is my duty to assure that MDB does not fail for causes that Manuel-Lemos-detractors opportunistically blame on Metabase . It is very likely that I never will use PEAR code. It is nothing personal to anybody. I just disagree with the design and the silly style requirements. PHP is not Python to force to users to adhere to one design only. I can't be bothered to repeat myself on this. It is up to PEAR people to realize that forcing one style is more bad than good. Just go to comp.lang.php and read on a thread about why people is not adopting PEAR and you can see that this is not just a problem with Manuel Lemos or Andrei Zmievski. I am pretty much self-sufficient with the PHP components that I have developed and will continue to satisfy my projects' needs, so I don't use any of the classes of other developers that contribute to PHP Classes. So, I am not being biased here.

If I do things differently than you recommend it is sometimes not for technical but for diplomatic reasons. I have to please a lot of people for them to accept MDB. I hope the choices I am making will not turn off to many people.

I think the reasons are silly but I understand why you have them . Anyway, I was not telling you to not give certain steps like PEARifying code, but rather to give it a lower priority than other much more important things like migrating all drivers to MDB. Regards, Manuel Lemos

-----Original Message----- From: Manuel Lemos [mailto:mlemos@acm.org] Sent: Friday, September 06, 2002 12:40 AM To: metabase-dev@yahoogroups.com Cc: pear-dev@lists.php.net; dev@binarycloud.tigris.org Subject: Re: [PEAR-DEV] Re: [metabase-dev] MDB news (http://pear.php.net/package-info.php?package=MDB) Hello, On 09/04/2002 07:19 PM, Lukas Smith wrote:

From: Manuel Lemos [mailto:mlemos@acm.org] Sent: Wednesday, September 04, 2002 3:47 PM Anyway, I also noticed that you assume a default for dates that is

not

valid for most databases and even less is portable. 0000-00-00 is a

date

that never existed. The date count after Christ started in

0001-01-01

.

The year before 1 is -1, not 0. Still, even if you assumed 0001-01-01 as default, not all databases allow arbitrary ranges of 4 digit years . Some do not allow dates

before

1970 or 1900.

I will look into this issue after 1.0 more deeply. For now I guess its atleast a step in the right direction to rather

use

0001-01-01. But it is only relevant for the reverse engineering

really

and people will have to manually edit the resulting xml schema file anyways until further advancements are made (like an interactive application etc).

This is really not that important. It was just an example of one thing that you are doing that will break with other databases because you

were

not aware of the valid ranges of dates. Anyway, 1) it should be up to the driver to assume defaults if really needed, 2) if needed, the drivers should assume defaults with safely dates like 2000-01-01 , 3) if you really want to be sure that all drivers return defaults for not null fields, throw an error in the manager class regarding that problem so it does not go unnoticed when

a

developer writes a new driver.