(improvement) makemigrations app_label can and should always create migration only for this app_label

[nnseva]

Hi All,

The %subj% is a discussion for the ticket https://code.djangoproject.com/ticket/30467

The theme has been touched also in the following threads:
https://groups.google.com/forum/#!searchin/django-developers/makemigrations$20dependency%7Csort:date/django-developers/WgFacUFvgfs/cDoYO018NzIJ
https://groups.google.com/forum/#!searchin/django-developers/makemigrations|sort:date/django-developers/iClIpvwlbAU/53ZBk-y_AgAJ

https://groups.google.com/forum/#!searchin/django-developers/makemigrations|sort:date/django-developers/IG5ZSRRp8Rw/a0VSjrJMAQAJ

What happens?

Now, if the makemigration is running for the only app_label A, it sometimes tries to create a migration for other app_label B implicitly, if the A contains a ForeignKey field referring a model in the B with the unsynchronized state.

What proposed?

Always avoid implicit migration creation for the referred application B.

Why the makemigrations CAN always do it?

If the application A has a ForeinKey reference to the application B without migrations, it means, that all tables in the application B are already created on the stage of initial migration and need not be migrated.

If the ForeignKey in the application A refers to the existent (in the migration state) model of the application B, but with the not synchronized state, the created migration may depend on the last existent migration of the application A instead of newly created one almost anyway.

The only inconsistent unsynchronized change leading to possible errors may be:

- changing the primary key of the referred model in application B

- creating a brand new referred model in application B

Change in the primary key leads to changes in the ForeignKey field attributes, implicit, or explicit. Such a change may be detected separately and agnostic way: determining changes only in the ForeignKey field attribute values.

Non-existent referred model in the state can also be detected easy, and leads to other error detected on the stage of migration itself, or while runtime (non-existent table for the model).

Such an inconsistent unsynchronized change may lead to error message generated by the `makemigrations A`, like `the application A refers to the application B which needs to have synchronized migration state, please create a migration for B first`.

Why the makemigrations SHOULD always do it?

What is application B? It may be:

- own project application

- third-party application

If application B is own project application, the project owner always can explicitly create a new migration for the application B to synchronize its state. Such a way, it is enough to have an error message such described above instead of implicit creation of such a migration creating migration for application A.

The most problem is a third-party application.

The third-party application is such a thing that should not be changed by the programmer. It is installed in the system area or virtual environment as a rule.

If the third-party application B is installed into the system area, the `makemigration A` command will lead to file access error if tries to create a migration for application B automatically.

If the third-party application B is installed into the virtual environment, the `makemigration A` command will lead to migration conflict, and/or refer to non-existent migration in case of shared development of the project.

Why the third-party application may have inconsistent migration state?

1. Of course, the third-party application B can really have inconsistent migration state because of third-party programmers error. If such a problem is significant for the project, it is detected by the error message described above, or others, which allow the programmer of the project to make an explicit decision, what to do next.

The project programmer can create a lost (temporary) migration for application B, it is a resolution compatible with the existent now. He also can avoid using this application at all, create an issue in the tracker, etc... Anyway, the programmer makes a decision explicitly and knows about all the effects of it.

2. The inconsistent migration state may also be caused by dependencies of settings, different in the application when migration for B has been created, and project when the migration for A is created.

Such a dependency may lead to insignificant changes in the model state which don't change ForeignKey attributes. It might be changing in field verbose name, enum field choices, file field storage, or other field attributes not related to the database table metadata state.

Unfortunately, even the solution with the __eq__ substitution described in the documentation does not work to avoid unnecessary migration detection in such a case. A field attribute value of the complex deconstructible type leads to wrong state inconsistency detection when changed, even when have an __eq__ substitution, because of doing deep_deconstruct results comparison instead of direct comparison in the Django code.

With best regards,
Vsevolod Novikov