Why is django not creating a database table with 'migrate' command

Question

I am new to Django, and for some odd reason my models are not creating a database table and am completely clueless as to why. When I run the command: "python manage.py makemigrations" I get the following shows up int he console output:

Migrations for 'auctions':
  auctions/migrations/0001_initial.py
  - Create model User
  - Create model Item

Which appears to be accurate to me. So then I run the command: "python manage.py migrate" and the following shows up in the console output.

Operations to perform:
  Apply all migrations: accounts, admin, auctions, auth, contenttypes, sessions
Running migrations:
  No migrations to apply.

Looking into the database and sure enough nothing was created. Below is output of my models.py file:

from django.contrib.auth.models import AbstractUser
from django.db import models



class User(AbstractUser):
    def __str__(self):
        return f"{self.first_name}"


class Item(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE, related_name="item_list")
    title = models.CharField(max_length=64)
    description = models.CharField(max_length=256, blank=True)
    img_url = models.CharField(max_length=256, blank=True)
    starting_bid = models.DecimalField(decimal_places=2, max_digits=8)
    category = models.CharField(max_length=24, default='No Category')
    status = models.BooleanField(default=True)

    def __str__(self):
        return f"{self.title}, {self.description}"

This is the output of the command: "python manage.py showmigrations"

Glass-Bids nobility$ python manage.py showmigrations
access
 (no migrations)
accounts
 [X] 0001_initial
admin
 [X] 0001_initial
 [X] 0002_logentry_remove_auto_add
 [X] 0003_logentry_add_action_flag_choices
auctions
 [X] 0001_initial
auth
 [X] 0001_initial
 [X] 0002_alter_permission_name_max_length
 [X] 0003_alter_user_email_max_length
 [X] 0004_alter_user_username_opts
 [X] 0005_alter_user_last_login_null
 [X] 0006_require_contenttypes_0002
 [X] 0007_alter_validators_add_error_messages
 [X] 0008_alter_user_username_max_length
 [X] 0009_alter_user_last_name_max_length
 [X] 0010_alter_group_name_max_length
 [X] 0011_update_proxy_permissions
 [X] 0012_alter_user_first_name_max_length
contenttypes
 [X] 0001_initial
 [X] 0002_remove_content_type_name
sessions
 [X] 0001_initial

Please show the output of python manage.py showmigrations. — Melvyn

Melvyn Melvyn · Accepted Answer · 2021-03-20T15:42:07

Yep, as I thought. You probably followed someone's advice that said "delete all migrations and delete the tables" and now there is still a record in the django_migrations table that says "0001_initial" for the auctions app has already been applied. Since 0001_initial is the name that will be created time and again for an app without migrations, you can't get out of the situation.

So first, use your favourite database tool, to delete the offending row:

melvyn=# SELECT app, name FROM django_migrations WHERE name='0001_initial';
     app      |     name     
--------------+--------------
 contenttypes | 0001_initial
 auth         | 0001_initial
 admin        | 0001_initial
 sessions     | 0001_initial
 account      | 0001_initial
 sites        | 0001_initial
 main         | 0001_initial

So in your case: DELETE FROM django_migrations WHERE app='auctions';

Now the migration will be applied if you run migrate.

For next time: never delete all migrations if this advice is given without a solid explanation. It's a time waster and only helps in limited situations and is more often the cause of problems.

The migrate command can rollback migrations as well, so if you're not happy with any of the migrations do:

% python manage.py migrate auctions zero

(yes, literally the word zero). This will revert all migrations of the app.

If you're unhappy with your latest change, set it back one number. So if an app has 3 migrations, do:

% python manage.py migrate auctions 0002

Then you can throw away migration 0003, change your models and run makemigrations again and migrate again.

That way, django's assumptions about applied migrations stays in sync with your code.

Why is django not creating a database table with 'migrate' command

1 Answers