Migration performance, interfaces and flexibility

In terms of the reload_model issue it has been recently discussed in this thread Migrating backwards takes orders of magnitude longer than migrating forwards.

It is a well known problem on which we made some progress over the past years by making sure that built-in Operation subclasses only operate from ModelState and not rendered model.

This means that under normal circumstances generating the project state up to a certain point (e.g. 1000’s of migration already applied) which is basically a series of state_forwards call is relatively fast as no model rendering takes place.

Things begin to get slow once you apply your migration operations on the database though as the schema editor still operate from rendered model. This means that from that point models are rendered and need to be invalidated on state_forwards and re-rendered on followup database_forwards.

It is a problem we’ve been trying to solve for a while and was also publicly discussed.

1 Like