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

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

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.

Yes, but you are still missing my point precisely because you do not have the experience with the others that are for sure much more difficult to deal with, you have no idea of the feasibility of the any new features that you may add to MDB.

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.

Lukas, read me with attention for once: the problem is not the importance of the features you want to add. The problem is that you do not have enough experience to figure if the such features will work right with all the other databases that you have not experienced. The need for other drivers is that so you gain experience and understand the possibilities and limitations of such databases. Untill you do so, chances are that you keed adding features that will not work right with the databases you don't know.

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.

Sure, but the problem is that you should not need to depend on me to know that somethings you add are odd because you assume they will work well with other databases.

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.

I know that. That is why the schema parser requires not null fields have a default although some databases do not require it. I had already a discussion in the past with a user that wanted to remove that restriction. That would be bad because it would not warn users about something that would not be portable, so I did not remove that restriction. Anyway, my point is not that you assume default values. The point is that should be the role of the manager driver class, not the manager class itself. See what I mean now?

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.

I understand and agree with that goal, but my point is that it is more important that you gain more experience with all supported databases before you jump on new features. I am right to wait because it gives more time to reflect on a way to provide that that works well with all databases. I can tell you right now that it is even more difficult than I thought.

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.

Of course. That is why, adding more features now will make porting other drivers more difficult later and take even more time to do it.

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.

This is the kind of reasoning that makes MDB happen even later than before. Why on earth do you insist on spending time to rewrite something that works now and well? Don't you think that there are more prioritary things that should be address first? -- Regards, Manuel Lemos