great that you’re interested in this . Where do you want me to start to elaborate on the idea?
Some things that will probably be necessary these:
To really know about all dependencies between all models, I’d go about and have a central registry, probably on
django.apps.registry.Apps. You need some kind of structure that allows quick look-ups of the form “which models point to a given model”. But, more precisely, you probably need that on a field level. What are all the fields (and from them you can derive the corresponding models) that point to a given field or a given model. You need this be able to lookup which related models need to be touched when e.g. another model is deleted
You will also need a mapping that gives you information about data types of related columns. Currently a
ForeignKey retrieves its
self.target_field which depends on the model instance. This is necessary as the
column_sql() depends on
I suspect these one or two things to be the first major milestones. I didn’t take these steps in my proof of concept and eventually that became one or the core problems I ran into.
The second major issue I was facing was the backwards compatibility requirements on the
SchemaEditor. Anything you do will have to keep working as-is, even with model classes because the API is documented. You can deprecate parts, but their removal will only happen in the next major major release series (simply put). I think making the
django.db.migrations.state behave identically to model classes could help there. But I haven’t investigated any further what that would entail.
I hope that helps