Re: Lets not solve Schema Evolution but reframe the problem

[Russell Keith-Magee]

On Wed, Apr 29, 2009 at 10:42 AM, DavidP  wrote:
>
> A  solution to the schema evolution problem is to reframe it and solve
> a different problem.

While I'm glad you are enthusiastic about the schema evolution
problem, now is not the best time to be discussing it. We are trying
(desperately) to get v1.1 out the door, and design discussions that
aren't explicitly on the v1.1 path only serve to distract the
community. If you could hold off on discussions such as these until we
are in the v1.2 feature discussion period, we would be much obliged.

I would also note that code speaks much louder than words. If you
think that you have a magical solution for schema evolution, code up a
proof of concept. Then you will be in a much stronger position to
argue your case.

> The "problem" with schema evolution is caused by a violation of the
> DRY principle. There is redundancy between the db schema and
> django's .py files.   The DRY violation may be removed by coding an
> application definition as per-application meta data annotations of the
> database itself. The meta data must be guaranteed to survive arbitrary
> changes to the schema by ALTER statements and disappear when a column
> or table is DROP'ed.
>
> In mySQL, one way of anchoring meta data to the schema is to store a
> GUID in the table and column comment fields in the database
> information_schema.  The data in comment field survives ALTER
> statements and will disappear after DROP statements and may be used as
> the keys for linking meta data to the schema.
>
> With these GUID’s in place, an application's specific django
> annotations (e.g. verbose_name=”", whether or not a field is visible
> in the application etc) may be stored in an a per-application
> definition table and the django models.py, admin.py, ... files may be
> regenerated at any time based on introspection of the database
> information_schema + this application's annotations.
>
> Bingo.

While I'm sure you are convinced of the efficacy of your solution, you
need to keep the following in mind:

 * Your solution needs to be database independent. Any solution you
propose needs to work with databases other than MySQL.

 * Django currently treats the Python model as canonical. If you're
proposing that we change this approach, you're going to need to show
how database changes can be reflected in Python. It isn't clear to me
how your proposal will maintain Python model logic, such as validation
and other utilities, when the database is reflected back into Python
code.

 * It isn't clear to me how your proposal will be able to handle
manual database changes. If a database manager adds a new field or
modifies an existing field on a Django model, but doesn't update the
metadata, how does this whole process work?

Schema evolution is a hard problem. People proposing easy solutions
are going to be treated with skepticism. This doesn't mean your
solution is wrong, but you need to be prepared to defend your
proposals - preferably when the rest of the community isn't trying to
push a release out the door.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Lets not solve Schema Evolution but reframe the problem

[DavidP]

A  solution to the schema evolution problem is to reframe it and solve
a different problem.

The "problem" with schema evolution is caused by a violation of the
DRY principle. There is redundancy between the db schema and
django's .py files.   The DRY violation may be removed by coding an
application definition as per-application meta data annotations of the
database itself. The meta data must be guaranteed to survive arbitrary
changes to the schema by ALTER statements and disappear when a column
or table is DROP'ed.

In mySQL, one way of anchoring meta data to the schema is to store a
GUID in the table and column comment fields in the database
information_schema.  The data in comment field survives ALTER
statements and will disappear after DROP statements and may be used as
the keys for linking meta data to the schema.

With these GUID’s in place, an application's specific django
annotations (e.g. verbose_name=”", whether or not a field is visible
in the application etc) may be stored in an a per-application
definition table and the django models.py, admin.py, ... files may be
regenerated at any time based on introspection of the database
information_schema + this application's annotations.

Bingo.

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---