# GSOC 2020 Migration Project

**URL:** <https://forum.djangoproject.com/t/gsoc-2020-migration-project/1286>\
**Category:** Google Season of Code\
**Created:** [February 26, 2020, 5:29am UTC](https://forum.djangoproject.com/t/gsoc-2020-migration-project/1286 "2020-02-26T05:29:40Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![MarkusH](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/markush/32/19_2.png) [@MarkusH](https://forum.djangoproject.com/u/MarkusH)\
**Post date:** [February 27, 2020, 7:12pm UTC](https://forum.djangoproject.com/t/gsoc-2020-migration-project/1286/6 "2020-02-27T19:12:00Z")

</div>

Hi @jc4883,

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 `db_type` from `self.target_field`](https://github.com/django/django/blob/a4881f5e5d7ee38b7e83301331a0b4962845ef8a/django/db/models/fields/related.py#L1000-L1001) which [depends on the model instance](https://github.com/django/django/blob/a4881f5e5d7ee38b7e83301331a0b4962845ef8a/django/db/models/fields/related.py#L710-L722). This is necessary as the `SchemaEditor`'s [`column_sql()` depends on `db_type()`](https://github.com/django/django/blob/a4881f5e5d7ee38b7e83301331a0b4962845ef8a/django/db/backends/base/schema.py#L212).

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 `ModelState`s 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 🙂

---

_[View the full topic](https://forum.djangoproject.com/t/gsoc-2020-migration-project/1286)._