Allow management commands to check if database migrations are applied

[Maxime Lorant]

​https://github.com/django/django/pull/5643

[Shai Berger]

Hi,

Thanks for filing this report and patch. I think the patch is not an improvement, though:

• The claim that you must run "migrate" is not true, the table could be created in other ways;
• Since the user model is swappable, many interesting things could be different from default;
• I suspect other database backends will throw different errors here;
• I suspect the sqlite backend will throw an OperationalError in different circumstances (e.g. the database file cannot be written to because of permissions or non-existing directory or device full or whatever)

The error message, in general, could be made friendlier, but the source error must not be hidden. I think we could accept a similar modification where the except: clause catches DatabaseError, prints a hint along the lines of "Have you run initial migrations for this project?", and re-raises the exception.

For a test, I think you should try to temporarily swap out the user model; that should create the invalid code-vs-database state to trigger the exception.

[Tim Graham]

I don't see much advantage to this. In my opinion, a developer should be able to understand what the lack of a database table means. There are other management commands that access the database -- do they all need to be adjusted too?

[Maxime Lorant]

I agree with you, a developer should understand that a missing table on a Django default command means the database has not been created yet. However, I sometimes answer to question on StackOverflow or other programming forums even more... easy *cough*... (like "Why my page is not working and throw name 'url' is not defined in urls.py").

After some thoughts, the idea to raise the exception again with a hint seems more friendly for both usages (new Django users and skilled one), but it is not urgent at all. Also, it needs to establish a list of commands to improve...

[Tim Graham]

I don't think the exception catching solution would work perfectly. For example, there's no guarantee that the database exception is due to missing tables and not some other bad query, etc. A more viable solution might be to allow management commands to check if all database migrations are applied and to output a warning if not, similar to what runserver does. Accepting the ticket for investigation of that idea. #24484 is similar.

[Shai Berger]

FWIW, +1