Django has won me over. But it can be improved!

Delivering web applications using django is a sublime experience – its core ‘do not repeat yourself’ philosophy and the built in admin application makes development of applications easy and fun.

There remains however a major source of “repeating yourself” with django. The schema in the database is separate from the application definition in .py files.  This separation can currently be addressed in two ways neither of which are entirely satisfactory.

1. The django admin inspectdb utility will create a basic application definition from an existing database.
2. The django admin syncdb utility will create tables in a database from a django application definition.

However, neither of these utilities solve the problem of keeping a database and an application synchronised under incremental change.

This situation could be improved by defining the application as a meta-data annotation of the database.
If the application is an annotation of the database then irrespective of how the database structure is changed, the application will be simultaneously updated and vice-versa.
Notes on a candidate solution
A core issue is making 1-1 correspondence links between tables and columns in the database and django application annotations. These links need to survive arbitrary sequences of ALTER statements, and disappear after DROP statements.  In mySQL, one way of doing this would be to store a GUID in the table and column comment fields in the database information_schema.  The comment field survives ALTER statements and will disappear after DROP statements.

With these GUID’s in place, all the django specific annotations (e.g. verbose_name=””) 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 applications annotations.