﻿id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
36170	Running no-op migrations (verbose_name, ...) slow on sqlite	Klaas van Schelven	Ahmed Nassar	"Running no-op migrations (verbose_name, help_text, choices) triggers DB-wide check_constraints on sqlite

This is because [https://github.com/django/django/blob/5da3ad7bf90fba7321f4c2834db44aa920c70bc7/django/db/backends/sqlite3/schema.py#L39 this is done as part of the DatabaseSchemaEditor's exit] which is [https://github.com/django/django/blob/5da3ad7bf90fba7321f4c2834db44aa920c70bc7/django/db/migrations/executor.py#L252 unconditionally called as part of apply_migration].

Because [https://code.djangoproject.com/ticket/21498 no-op migrations cannot be ignored by design] (also [https://code.djangoproject.com/ticket/30048 here]) this means that changing your help-text will lead to an unnecessary check of all constraints in the database (if no workarounds are employed, e.g. squashing with something else).

If we accept the principle of ""no ignoring of fields on-detect"" as per the issues mentioned above, we might still try to detect the fact that for any given field and DB nothing happened in practice (and hence no check_constraints is needed)

In particular: the call to `check_constraints` was introduced as part of [https://github.com/django/django/commit/7289874adceec46b5367ec3157cdd10c711253a0 this commit], in which it is directly tied to a 5-step process.

Without claiming to have fully thought through all consequences: can't we pull the check closer to those 5 steps, or make it conditional to `_remake_table` having been actually called between enter & exit?

**Refs / background:**

I'm doing this in the context of [https://www.bugsink.com/ Bugsink, a Self-hosted Error Tracker]; SQLite is a first level citizen (for production) in that tool, which means large databases can be expected. On a not all too big ~100K-row database I timed the above unnecessary check to take ~20 seconds. Scaling that up by 1 or 2 orders of magnitude would be my goal. Charitably assuming linear growth in time-complexity, you can see how this can quickly become ''really annoying.''

[https://stackoverflow.com/a/39801321/339144 this SO post] provides tricks for avoiding the creation of such migrations in the first place (may be relevant context as long as the above isn't fixed yet).
"	Cleanup/optimization	assigned	Migrations	5.1	Normal				Accepted	1	0	1	1	0	0
