RE: [PEAR-DEV] Re: [metabase-dev] MDB news (http://pear.php.net/package-info.php?package=MDB)
| From: | Lukas Smith | 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