Creating model classes for test purposes breaks migrations

[Paolo Dente]

Defining a model class in a test file like this:

class BasicModel(models.Model):
    title = models.CharField(max_length=255)

results in the test breaking immediately with a CommandError:

CommandError: Database test_db couldn't be flushed. Possible reasons:
  * The database isn't running or isn't configured correctly.
  * At least one of the expected database tables doesn't exist.
  * The SQL was invalid.
Hint: Look at the output of 'django-admin.py sqlflush'. That's the SQL this command wasn't able to run.
The full error: relation "appname_basicmodel" does not exist

Since it is no longer possible to disable migrations for testing, a possible solution would be either allowing specific models to be marked as non-migrated, or avoiding flushing of non-existing tables.

[loic84]

Hi @pgcd, do you have the admin (django.contrib.admin) in your INSTALLED_APPS? If so, could you try commenting it out before running django-admin.py sqlflush?

[Paolo Dente]

Hi @loic84 - yes, I do have the admin installed but commenting it out does not change the result. Please note, though, that I am not running django-admin.py sqlflush directly (and when I do, it doesn't detect the test model, so it works correctly); the problem is only when running the tests.

[Claude Paroz]

Note that I was also confronted to this while trying to provide initial migrations for contrib.auth app (#22170). I workarounded it by also adding a migrations folder in the tests, and specifying MIGRATION_MODULES (see ​https://github.com/claudep/django/commit/05af8e787e22e5fd5894fd1f3069df7a9fd40fc3).

But It's definitely a realm where a better solution should be provided.

[Tim Graham]

Duplicate of #7835 (some official way to support models in tests).