1. Phenomenon
A table is deleted in the database, and an python manage.py migrateerror occurs when re-executing, indicating that the table does not exist.
Two, the cause
Mainly because a new table is djangogenerally created during the first migration, and the subsequent ones will not create a new table, but only check the changes of fields, etc., so since we have deleted this table, djangocheck the field changes of this table. It's time to be wrong.
3. Solutions
The solution is still to execute the python manage.py makemigrationssum python manage.py migrate, but before executing this, delete the record that created the table for the first time when the migration is executed , otherwise it detects that it has been executed for the first time, then it will not create the table later.
(1) Under this appmodule, there is a migrationsfolder. Except for the first two files, other files are deleted. In fact, every time there is a change, a file will be generated here. The 001_initial.pyname below shows that it is the first file. It is generated during a migration, that is, because of its existence, the table will not be created every time it is executed in the future.
(2) Secondly, there are corresponding records in the database, which should also be deleted. Let's take a closer look at what is stored in the database. django_migrationsInside, this table stores the records of each migration. Of course, what modules are recorded and the corresponding file names. For example, the module dthemehere is the file name here. It is 001_initialone-to-one correspondence with our folder. Similarly, delete this record.
Then execute the python manage.py makemigrationssum and python manage.py migratethat's it. It should be noted that if appthere are other modules under this module model, other modelcreated ones 表should also be deleted, which is equivalent to our solution is for the entire appmodule, and it will be regenerated if it is to be executed, otherwise it will prompt some tables. errors that already exist.