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

From: Date: Sat, 07 Sep 2002 10:24:56 +0000
Subject: RE: [PEAR-DEV] Re: [metabase-dev] MDB news (http://pear.php.net/package-info.php?package=MDB)
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-8915@lists.php.net to get a copy of this message
> From: Manuel Lemos [mailto:mlemos@acm.org] > Sent: Saturday, September 07, 2002 4:01 AM > > Hello, > > On 09/05/2002 07:38 PM, Lukas Smith wrote: > > You are right we need more drivers. > > Anyone reading this: Please contact me about porting drivers. > > I am afraid it does not work like that. But I am going to stop wasting > time argueing why because it is pointless. It seems it results better > that people learn at their own expense if they are not very motivated to > learn from the experience of others. > > > > About the default values: > > Yeah you are right I ran into issues with the reverse engineering etc. > > That is why I want to redesign the manager. > > I don't see the relation of that with wanting to redesign something that > works already. > The default values only matter during xml reverse engineering (see further comments further down this email) > > > But the default values cant really be moved to the driver either, > > because the schema files should work in any database -> least common > > dinominator where emulation is not feasible. But yeah .. all of this > > needs more thought. > > But schemas are validated when they are parsed and no parsed schema > contains not null fields without defaults. I know because I made the > parser work that way, remember? I don't know if you scraped that feature > when you rewrote the schema parser, but the reason why I did it is > because some database return an error when you attempt to create alter a > table with a not null field without a default value. > > The reason why it should be part of the driver functions, is that it is > their responsability to return field definitions that are portable. If > you relay that responsability to the manager, if somebody writes a > manager replacement or some other application that interfaces with the > schema reverse engineering functions directly, you would not have the > guarantee of having default values for not null fields because you > decided that it should be only the manager responsability. > > > Then again xml reverse engineering will not be perfect today, but its > > necessary to help adoption. > > Yes, but as I said over and over again rushing the first solution that > comes to your mind is usually a bad idea based on my long time > experience. You may choose to not consider what I saying, chances are > that you end up scraping your initial solution and leave everybody that > relied on it in the cold. > The redesign is mainly related to certain things that are not very easily extensible and therefore prevent moving forward quickly with things like a frontend to MDB/Metabase databases. For example the current way the method resonsible for dumping database schemas works is pretty hard to extend because all of the tags are hardcoded including the intention levels etc. If I for example want to write a comment into those fields when the schema was build using xml reverse engineering I have to ensure that I am using the right intention level etc. It would be much nicer if I would just say "dump this tag at this intention level" because then it is much more transparent. But this is just an example. We have found that a frontend to MDB/Metabase databases needs certain method that currently don't exist. So it's not about changing things that work but more about either extending things or making sure that things can be extended easily. So its not about making changes that provide zero benefit. This is what MDB is about from the onset and has been the reason for most of the changes done to the Metabase codebase during MDB development. It is also related to integrating the xml reverse engineering, because you are right the current support is quite rushed. This needs some thought and I very much want you to be part of this (that is why I wrote this email). I have made the decision to leave this "rushed" xml reverse engineering in MDB until I have a better alternative. This is a decision that I have made to increase adoption. Regards, Lukas

« previous php.pear.dev (#8915) next »