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

Hello, On 09/04/2002 06:27 AM, Lukas Smith wrote:

I will release RC3 tonight or tomorrow morning. And hopefully 1.0 final by the end of the week. During the release cycle we found that there are some problems with the current API in the manager(*). Some are a result of the addition of the xml reverse engineering, others have surfaced during the development of the MDB_frontend(**). Therefore the manager will see a lot of changes after the 1.0 release. I will try to keep the old external API intact as much as possible. So hopefully any changes will only have minor (if any) effect existing scripts. For this I need a list of features that this new manager should have.

From this I will build a new and more complete API (keeping in mind

backwards compatibility). Once that is done I will start writing the new manager (probably with a lot of cut and paste from the old manager).

It seems to me that you puting the horses ahead of the carriage. 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. The reason is simple: until you have a real feeling of what are the diferences between each database API, you will never be sure what is or it isn't feasible to do with all databases. Basically you only have worked with MySQL. Certain things that are valid in MySQL may well not be valid in other databases. I don't have much time to analyse and comment the changes you make to Metabase original behaviour in MDB. However, sometimes I notice some things that seem odd and that soon or later you will realize that they are not portable at all. For instance, just the other day I noticed that you are assumming default values for each default values for reverse engineered not null fields that do not come with a default. This is wrong because all not null field should come with a default value. If they don't come with one default value, the problem should be fixed in the drivers, not in the manager class that should be as database independent as possible. 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. This is the point I am getting at. If you have already ported and tested all drivers you would most likely realized that. This is why I recommend that you do things in a order that will help you to prevent adding features that may not be feasible with all databases, thus defeating the true database portability spirit that is the standard of Metabase. Another point is that you should try to discuss new features before you assume they can be added assuring portability. If you do not discuss with other people that have expirience with other databases besides MySQL, that is a sure reciepe for API unstability that will always discourage wise people to adopt new features. 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. You should hold your anxiety to release new things without further reflection after their first versions are implemented. That would give you a chance to rethink the new features with more appropriate API if you realize their first implementation attempt was inconvinient. Just so you have an idea, Metabase first public version was only released one year after it was started precisely because I wanted to be sure that its API was stable and safe from any backwards incompatible changes. I only released it when I had 6 drivers developed and tested properly.

So please mail me all the features you want to see in the manager. Please note if this feature allready exist in the current manager or not, just to make my life a bit easier.

As I mentioned, you should tell and discuss what new features you have in mind. It may be pointless to ask other people for feature suggestions because that may not happen as most people are not feeling secure to use MDB yet, even less to have any idea of what features they would like to have. -- Regards, Manuel Lemos