Re: Re: [metabase-dev] MDB news (http://pear.php.net/package-info.php?package=MDB)
| From: | Manuel Lemos | Date: | Sat, 07 Sep 2002 02:01:25 +0000 |
| Subject: | Re: 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-8903@lists.php.net to get a copy of this message | ||
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.
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. -- Regards, Manuel Lemos