GSOC 2020 Migration Project

Hi @jc4883,

great that you’re interested in this :+1:. 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 db_type from self.target_field which depends on the model instance. This is necessary as the SchemaEditor's column_sql() depends on db_type().

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 ModelStates from 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 :slight_smile:

2 Likes