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

Hi, > > 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. Well we do also have a PostGreSQL driver. And yes you are right we need more drivers. I am willing to help anyone write or better port a driver, but this is something where the community needs to step up. The things I want to change do not only have to do with reverse engineering. For example I want to make it possible to just dump one table or sync to database structures etc. On the reverse engineering front I want to change exactly the tight integration with the rest of the API to make it more flexible for more database systems. So the redesign will actually help to make the manager more compatible with other RDBMS. But true: Drivers are even more critical to get MDB's adoption up. It will certainly make MDB more valueable to me. But since the manager is also critical to me and I do not have customers asking me for other DB's in the projects I have lined up til next year I have to choose my priorities. > 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. Well you certainly know more about different databases than I do. So any info will surely help. > 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. Well that is where the problem come from with the reverse engineering. A not null field needs to have a default value. But sometimes this is not the case. Basically I first ensure that all field with an index are set to not null. Then I ensure that all not null fields have a default value. Another good example that shows that reverse engineering needs to be seperated from "normal" methods. And I know you said that this stuff needs more thought. But on the other hand I am fighting for adoption of MDB and reverse engineering greatly eases this (myself included). I have added a note in the README.txt saying that the manager is still in flux. Those changes will not affect the core of MDB. > 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. That is correct of course. For reasoning see above. > 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. Yes, I should discuss things more. The problem is to some extend the classic chicken and egg issue. A large project such as this, with such a dependencies on even more complex software products (the RDBMS) needs a lot of thought. And time. I have given this project a lot of time allready. But now I need other people to become more active. The 1.0 release will be pretty good. The core API is pretty solid because it heavily builds on Metabase and to a lesser extend on PEAR DB, two established products. So now I want to reach a new level of support from the community. Once we have more drivers we will see a 1.1 release that should have a very stable API and the assurance that it will truly be portable. Until then everybody who jumps in the bandwagon has something to gain, but definitely takes the risk of having to make minor adjustments down the road. > > > 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. > I will also sit down and write down exactly what the features are today. I will then write down that I think is missing. Based on the existing API I will then extend the API. One thing I definatly want to do is break up the methods into smaller chunks. I also want to write a dumper so that the format (and indentition levels) or not hardcoded into database dumping methods like they currently are. Anyways I will get 1.0 done first and then move into the manager and helping people write drivers. So the 1.0 release should be seen as: Core 1.0 Manager 0.5 Regards, Lukas