Diagnose missing tables and schema-state mismatches

Understand the likely causes

• The process can load an unintended settings profile or connection, use a different relative SQLite file, lack an applied migration, run code ahead of the schema, or map a model to a different table. A restored or newly provisioned database can also have an incomplete history.
• A Python model declaration does not create its table, and editing a migration file that some environments already applied can make histories diverge further.

1. Preserve the first failure and release identity

Record the exception type, safe table or column name, request operation, runtime version, and application artifact identity. Keep credentials and private query values out of shared reports. Distinguish an unavailable connection from a successfully reached database that lacks the expected object. A permission error is another separate cause and should not be relabeled as a migration failure. Do not run destructive reset commands, fake migration state, or delete a SQLite file to obtain a clean-looking result. Preserve the evidence needed to explain which layer is inconsistent.

2. Confirm the selected settings and database identity

Inspect the approved settings source and connection alias in the same process context that failed. Compare engine, intended environment, and a safely redacted target identity rather than printing the entire DATABASES mapping. Relative SQLite paths can resolve differently when the working directory changes. Database routers or multiple aliases can select another connection for a model. A working shell on a developer’s laptop does not prove the deployed worker uses that target. Keep the diagnosis read-only until the intended resource and owner are established; the goal is not to discover credentials or connect to an unknown system.

3. Compare model mapping, schema, and migration history

Check the model’s actual database table mapping, the release’s migration files and dependencies, and the approved read-only schema/history evidence for the intended target. Model code, migration state, and actual database objects are three related facts, not synonyms. The complete program below demonstrates this distinction only in a fresh in-memory database: defining the model leaves its table absent until the fixture explicitly creates it. That fixture technique is not a production repair or a substitute for migrations. If histories disagree, investigate the specific missing or inconsistent operation and its prior application before designing a reviewed rollout.

from django.conf import settings
settings.configure(
    SECRET_KEY="synthetic-course-key",
    USE_I18N=False, USE_TZ=True,
    INSTALLED_APPS=[],
    DATABASES={"default": {"ENGINE": "django.db.backends.sqlite3", "NAME": ":memory:"}},
    DEFAULT_AUTO_FIELD="django.db.models.AutoField",
    ALLOWED_HOSTS=["testserver"],
)
import django
django.setup()

from django.db import connection, models

class Course(models.Model):
    title = models.CharField(max_length=100)
    class Meta:
        app_label = "lab"

table = Course._meta.db_table
print(table in connection.introspection.table_names())
with connection.schema_editor() as editor:
    editor.create_model(Course)
print(table in connection.introspection.table_names())

False
True

4. Propose the smallest compatible repair and verify it

The correction may be selecting the intended settings, publishing the correct code artifact, restoring a complete database, or applying a reviewed missing migration through the environment’s approved procedure. Evaluate data preservation, backend costs, compatibility with running application versions, and rollback limits before any write. Do not pretend a fake migration marker creates missing schema. After approval and the actual correction, verify the expected object, representative application reads and writes, constraints, and relevant tests on the authorized isolated or deployment target. Preserve the original failure and explain which mismatch the correction resolved.

Keep it from recurring

• Version migration files with the code, record deployment/database identity safely, and test migration replay and compatible rollout under disposable fixtures. Avoid changing already-applied history casually or treating production data as expendable test setup.