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 -~----------~----~----~----~------~----~------~--~---
