Django - 没有这样的 table 异常
Django - no such table exception
在 Django 中，我在 models.py 中添加了一些模型。在 manage.py makemigrations、manage.py migrate 引发此异常后：
django.db.utils.OperationalError: no such table: auth_test_usertranslatorprofile
所以我删除了所有旧的迁移并再次 运行 makemigrations 和 migrate 这似乎有效。
不幸的是，我注意到它没有帮助，因为当我尝试单击 User translator profiles 的 User customer profiles 时，它引发了异常：
环境：
Request Method: GET
Request URL: http://127.0.0.1:8000/admin/auth_test/usertranslatorprofile/
Django Version: 1.8.7
Python Version: 2.7.10
Installed Applications:
('django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'auth_test')
Installed Middleware:
('django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'django.middleware.security.SecurityMiddleware')
Traceback:
File "C:\Python27\lib\site-packages\django\core\handlers\base.py" in get_response
132. response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "C:\Python27\lib\site-packages\django\contrib\admin\options.py" in wrapper
618. return self.admin_site.admin_view(view)(*args, **kwargs)
File "C:\Python27\lib\site-packages\django\utils\decorators.py" in _wrapped_view
110. response = view_func(request, *args, **kwargs)
File "C:\Python27\lib\site-packages\django\views\decorators\cache.py" in _wrapped_view_func
57. response = view_func(request, *args, **kwargs)
File "C:\Python27\lib\site-packages\django\contrib\admin\sites.py" in inner
233. return view(request, *args, **kwargs)
File "C:\Python27\lib\site-packages\django\utils\decorators.py" in _wrapper
34. return bound_func(*args, **kwargs)
File "C:\Python27\lib\site-packages\django\utils\decorators.py" in _wrapped_view
110. response = view_func(request, *args, **kwargs)
File "C:\Python27\lib\site-packages\django\utils\decorators.py" in bound_func
30. return func.__get__(self, type(self))(*args2, **kwargs2)
File "C:\Python27\lib\site-packages\django\contrib\admin\options.py" in changelist_view
1550. self.list_max_show_all, self.list_editable, self)
File "C:\Python27\lib\site-packages\django\contrib\admin\views\main.py" in __init__
82. self.get_results(request)
File "C:\Python27\lib\site-packages\django\contrib\admin\views\main.py" in get_results
177. result_count = paginator.count
File "C:\Python27\lib\site-packages\django\core\paginator.py" in _get_count
72. self._count = self.object_list.count()
File "C:\Python27\lib\site-packages\django\db\models\query.py" in count
318. return self.query.get_count(using=self.db)
File "C:\Python27\lib\site-packages\django\db\models\sql\query.py" in get_count
466. number = obj.get_aggregation(using, ['__count'])['__count']
File "C:\Python27\lib\site-packages\django\db\models\sql\query.py" in get_aggregation
447. result = compiler.execute_sql(SINGLE)
File "C:\Python27\lib\site-packages\django\db\models\sql\compiler.py" in execute_sql
840. cursor.execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\backends\utils.py" in execute
79. return super(CursorDebugWrapper, self).execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\backends\utils.py" in execute
64. return self.cursor.execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\utils.py" in __exit__
98. six.reraise(dj_exc_type, dj_exc_value, traceback)
File "C:\Python27\lib\site-packages\django\db\backends\utils.py" in execute
64. return self.cursor.execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\backends\sqlite3\base.py" in execute
318. return Database.Cursor.execute(self, query, params)
Exception Type: OperationalError at /admin/auth_test/usertranslatorprofile/
Exception Value: no such table: auth_test_usertranslatorprofile
我正在附加我的文件：
MODELS.PY:
from django.db import models
from django.contrib.auth.models import User
class Language(models.Model):
shortcut = models.CharField(max_length=6)
name = models.CharField(max_length=50)
price_per_sign = models.FloatField()
class UserTranslatorProfile(models.Model):
user = models.OneToOneField(User)
languages = models.ManyToManyField(Language)
price_per_word = models.FloatField()
class UserCustomerProfile(models.Model):
user = models.OneToOneField(User)
ADMIN.PY:
from django import forms
from .models import Language
from django.contrib.auth.models import User
from django.contrib.auth.forms import UserCreationForm
class FreelancerRegistrationForm(forms.Form):
language = forms.ModelChoiceField(queryset=Language.objects.all().order_by('shortcut'))
你知道问题出在哪里吗？
谢谢
我用这些步骤解决了同样的问题：
- 删除项目目录中的数据库（
db.sqlite3 在我的例子中）
- 从项目子目录下的
__pycache__ 文件夹中删除所有内容
- 对于您要修复的应用程序，转到文件夹并清除
migrations 和 __pycache__ 目录
当您确定已清除上述所有文件后，运行:
python manage.py makemigrations
python manage.py migrate
希望对您有所帮助。
另一种情况会产生 没有这样的 table 错误。如果您的 views.py 或类似执行的代码在导入时尝试访问数据库，即导入 views.py 有副作用，那么 从头开始将行不通 。
当您的代码使用现有数据库时会发生这种情况，而现在您试图在没有数据库的情况下开始。只需更改 views.py 即可导入而不会产生副作用。如果您不想修复设计，请执行以下操作：
from django.db.utils import OperationalError
format_list = [('', '(all)')]
geom_type_list = [('', '(all)')]
try:
format_list.extend([(i[0],i[0])
for i in Format.objects.values_list('name')])
geom_type_list.extend([(i[0],i[0])
for i in Geom_type.objects.values_list('name')])
except OperationalError:
pass # happens when db doesn't exist yet, views.py should be
# importable without this side effect
添加到 terry_brown 的回答，这就是导致我出现问题的原因。我有一个带有 ForeignKey 的自定义用户模型到另一个模型。我将默认设置为数据库中的第一个对象。当我在数据库中有数据时它起作用了。但是当我从头开始时，它不起作用，因为它在导入时立即执行（所以甚至没有迁移）。
class User(AbstractBaseUser, PermissionsMixin):
subscription_plan = models.ForeignKey(SubscriptionPlan, default=SubscriptionPlan.objects.first().id)
我不得不牺牲 default（将其注释掉）。
更新：
更好的解决方案是使用初始迁移或固定装置预填充您的数据库。
可能没时间了但是...当我尝试 "clone" Django 1.11 安装到其他目录然后初始尝试管理 makemigrations 时我遇到了同样的问题。
我通过以下方式解决问题：
- 通过以下方式设置初始 Django 安装和创建主应用程序：
django-admin.py 启动项目app_name
初始迁移
管理 makemigrations，管理 migrate
设置超级用户：
管理创建超级用户
复制除主目录urls.py和settings.py之外的所有文件和目录（Django应用程序）
已将所有应用程序添加到 INSTALLED_APPS
管理 makemigrations，管理 migrate
从源 Django 应用程序目录复制 settings.py 和 urls.py
就是这样，没有错误，一切正常。
彼得
如果其他人遇到此问题并且接受的解决方案不起作用，请查看您的数据库路径，
数据库路径应该是绝对路径，
'NAME': '/pathto-db/default.db',
运行 命令下方。它解决了我一次这个问题
manage.py 迁移 --运行-syncdb
为了解决这个问题，我这样做了（在 Ubuntu 上，您需要调整 Windows 的命令）：
1.删除所有迁移文件
find . -path "*/migrations/*.py" -not -name "__init__.py" -delete
find . -path "*/migrations/*.pyc" -delete
2。删除 db.sqlite3
rm db.sqlite3
3。创建并 运行 迁移：
python manage.py makemigrations
python manage.py migrate
4.同步数据库：
manage.py migrate --run-syncdb
您需要删除数据库，这有点麻烦，但对于测试系统来说没问题。
从这个普遍优秀的资源中获得了除最后一步之外的所有内容：https://simpleisbetterthancomplex.com/tutorial/2016/07/26/how-to-reset-migrations.html
虽然 运行 任何管理命令 "django.contrib.admin" 会自动尝试发现和 admin.py 已安装应用程序中的模块。
如果有与数据库相关的代码，它会自动运行并尝试从数据库中加载数据，当它在数据库中找不到与 table 相关的数据时抛出此错误。
要修复此错误，只需将 INSTALLED_APPS 中的 "django.contrib.admin" 更改为 "django.contrib.admin.apps.SimpleAdminConfig"，它将阻止 "django.contrib.admin" 自动发现和 运行 管理模块。
django.contrib.admin automatically performs auto discovery of admin modules in installed applications. To prevent it, change your INSTALLED_APPS to contain 'django.contrib.admin.apps.SimpleAdminConfig' instead of 'django.contrib.admin'.
https://docs.djangoproject.com/en/3.0/ref/applications/#troubleshooting
如果上述解决方案的 none 对您有效，则添加 appname 以及 makemigration 和 migrate 命令。
makemigration login
migrate login
这可能会帮助您找出问题所在。
按照以下步骤解决此问题。
python manage.py migrate --fake APPNAME zero
这将使您迁移到假的。现在您可以 运行 迁移脚本
python manage.py migrate APPNAME
或
python manage.py migrate
表将被创建并且您解决了您的问题..干杯！！！
您不需要视图来进行迁移。注释掉 urls.py 中对其他应用程序的所有引用，清除数据库和旧迁移，运行 makemigrations，然后注释掉你的 urls.py。对我有用。
我阅读了其他团队给出的上述答案。
主要是要求删除 SQLite(DB) 并重置“迁移”文件夹。
如果您在生产环境中工作，那么这将不是正确的选择。
python manage.py migrate --fake APPNAME zeropython manage.py migrate APPNAMEpython manage.py makemigrations APPNAMEpython manage.py migrate APPNAME
这四个步骤足以解决这个问题。
我在创建模型时遇到了这个错误。
我打开了 db.sqlite3 文件并使用 SQLite 数据库浏览器为模型创建了一个 table。然后我创建了一个迁移并假迁移了它。不知道是什么原因导致了这个问题，但这个解决方法有所帮助。
我遇到了同样的问题。
None 以上解决方案对我有用。
当我添加一个新模型，数据库中有一些对象，然后我更改了模型名称时，这一切可能都开始了。
我需要从我的应用程序中删除整个模型，然后 运行 应用程序的管理页面。然后我通过在我删除它的所有文件中单击 ctrl + z 来恢复模型，最后我能够 运行 makemigrations 和迁移命令。
你会删除生产银行吗？
我看到很多都删除了sqlite，但是如果是生产行呢？
从 django_migrations table less contenttypes
中删除数据的解决方案
已经在tabledjango_content_type你远程app_label
在 migrations 文件夹中删除除 init.py
之外的所有内容
python manage.py makemigrations
python manage.py 迁移 --fake
这就是我解决应用程序重复问题的方法（安装插件后我有两个同名的应用程序）并且 django 创建了丢失的 tables，等等。
在我的正常功能情况下
我遇到了同样的错误。我用来解决这个问题的步骤是：
确保您的应用中有 migrations 文件夹。如果没有，在app文件夹中创建migrations文件夹，然后在文件夹中创建__init__.py文件。
如果migrations文件夹已经存在，则删除所有migration files。
删除默认为db.sqlite3的数据库文件。
运行命令python manage.py makemigrations
python manage.py migrate
修复我的错误的唯一方法是注释掉每个 单个文件。当文件认为数据库不为空或实际存在时，可能会发生此错误。
我刚刚注释掉整个项目，迁移，取消注释 models.py 文件，再次迁移，取消注释整个项目。我不知道它为什么起作用。
同样的错误并且没有删除数据库：
- 删除迁移
- 移除
__pychache__
python manage.py makemigrations --empty aliaspython manage.py makemigrations aliaspython manage.py migrate alias zero- 再次删除迁移
- 再次删除
__pycache__
python manage.py makemigrationspython manage.py migrate alias zero
其中别名是应用名称。
如果您删除了数据库并立即迁移，就会发生这种情况。
例如，如果您的错误提示没有 table table1 那么
- python manage.py makemigrations
- python manage.py 迁移
- python manage.py table1 app1
这里table1是table的名字，app1是table1 模型所在的 Django 应用名称。
使用 Django，我必须执行：
python manage.py migrate --run-syncdb
这个错误是因为Django的数据库导致的，这不是用户的错。它最简单的解决方案是使用不同的名称创建新的app。然后创建相同的模型然后运行pythonmanage.pymakemigrations 然后迁移。通过这样做你的错误应该得到解决
我知道这通常是通过删除开发过程中使用的 de sqlite3 数据库来解决的。
另外，我知道这个问题目前已经解决了，但我想把我的案例留在这里作为替代方案。
有时我们在编程时会更改模型中的很多东西。当我们 运行 python manage.py makemigrations 时，会在 app folder/migrations 中创建一个文件。当我们 运行 python manage.py migrate 在 table django_migrations 中创建一条记录。此记录包含 3 个字段，我们必须详细检查：
1 - 名称（这是在迁移应用程序文件夹中创建的文件名）
2 - 应用程序（这是我们应用程序的名称。也像命名空间一样工作以防止冲突）
3 - 已应用（这是执行迁移的日期时间）。
如果你以前修改过你的模型，你应该在迁移中有几个文件（数量与你在每次更改时执行 makemigrations 的时间相应），在我的例子中我想删除这些文件只是为了拥有一个迁移文件。
问题在于，当 makemigrations 再次 运行 时，它会创建一个文件 0001_initial.py。如果您还记得 table django_migrations 包含此文件的日志，这是为了防止执行迁移已经完成了。
如果是这种情况，您将从此 table.
中删除您的应用程序迁移记录
我对我的数据库做了一些改动，但遇到了同样的问题。 None 的解决方案对我有用，所以在花了几个小时后，我最终决定删除“db.sqlite3”文件并运行 makemigrations 和 migrate 命令。工作正常后。但是这个解决方案不是立即使用的好方法，只有在您没有选择时才使用它。
我遇到了同样的问题。我删除了所有迁移和 运行 这个命令
python manage.py makemigrations
python manage.py migrate --run-syncdb
它对我有用，数据也很安全（我没有丢失任何数据）
在 Django 中，我在 models.py 中添加了一些模型。在 manage.py makemigrations、manage.py migrate 引发此异常后：
django.db.utils.OperationalError: no such table: auth_test_usertranslatorprofile
所以我删除了所有旧的迁移并再次 运行 makemigrations 和 migrate 这似乎有效。
不幸的是，我注意到它没有帮助，因为当我尝试单击 User translator profiles 的 User customer profiles 时，它引发了异常：
环境：
Request Method: GET
Request URL: http://127.0.0.1:8000/admin/auth_test/usertranslatorprofile/
Django Version: 1.8.7
Python Version: 2.7.10
Installed Applications:
('django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'auth_test')
Installed Middleware:
('django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'django.middleware.security.SecurityMiddleware')
Traceback:
File "C:\Python27\lib\site-packages\django\core\handlers\base.py" in get_response
132. response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "C:\Python27\lib\site-packages\django\contrib\admin\options.py" in wrapper
618. return self.admin_site.admin_view(view)(*args, **kwargs)
File "C:\Python27\lib\site-packages\django\utils\decorators.py" in _wrapped_view
110. response = view_func(request, *args, **kwargs)
File "C:\Python27\lib\site-packages\django\views\decorators\cache.py" in _wrapped_view_func
57. response = view_func(request, *args, **kwargs)
File "C:\Python27\lib\site-packages\django\contrib\admin\sites.py" in inner
233. return view(request, *args, **kwargs)
File "C:\Python27\lib\site-packages\django\utils\decorators.py" in _wrapper
34. return bound_func(*args, **kwargs)
File "C:\Python27\lib\site-packages\django\utils\decorators.py" in _wrapped_view
110. response = view_func(request, *args, **kwargs)
File "C:\Python27\lib\site-packages\django\utils\decorators.py" in bound_func
30. return func.__get__(self, type(self))(*args2, **kwargs2)
File "C:\Python27\lib\site-packages\django\contrib\admin\options.py" in changelist_view
1550. self.list_max_show_all, self.list_editable, self)
File "C:\Python27\lib\site-packages\django\contrib\admin\views\main.py" in __init__
82. self.get_results(request)
File "C:\Python27\lib\site-packages\django\contrib\admin\views\main.py" in get_results
177. result_count = paginator.count
File "C:\Python27\lib\site-packages\django\core\paginator.py" in _get_count
72. self._count = self.object_list.count()
File "C:\Python27\lib\site-packages\django\db\models\query.py" in count
318. return self.query.get_count(using=self.db)
File "C:\Python27\lib\site-packages\django\db\models\sql\query.py" in get_count
466. number = obj.get_aggregation(using, ['__count'])['__count']
File "C:\Python27\lib\site-packages\django\db\models\sql\query.py" in get_aggregation
447. result = compiler.execute_sql(SINGLE)
File "C:\Python27\lib\site-packages\django\db\models\sql\compiler.py" in execute_sql
840. cursor.execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\backends\utils.py" in execute
79. return super(CursorDebugWrapper, self).execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\backends\utils.py" in execute
64. return self.cursor.execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\utils.py" in __exit__
98. six.reraise(dj_exc_type, dj_exc_value, traceback)
File "C:\Python27\lib\site-packages\django\db\backends\utils.py" in execute
64. return self.cursor.execute(sql, params)
File "C:\Python27\lib\site-packages\django\db\backends\sqlite3\base.py" in execute
318. return Database.Cursor.execute(self, query, params)
Exception Type: OperationalError at /admin/auth_test/usertranslatorprofile/
Exception Value: no such table: auth_test_usertranslatorprofile
我正在附加我的文件：
MODELS.PY:
from django.db import models
from django.contrib.auth.models import User
class Language(models.Model):
shortcut = models.CharField(max_length=6)
name = models.CharField(max_length=50)
price_per_sign = models.FloatField()
class UserTranslatorProfile(models.Model):
user = models.OneToOneField(User)
languages = models.ManyToManyField(Language)
price_per_word = models.FloatField()
class UserCustomerProfile(models.Model):
user = models.OneToOneField(User)
ADMIN.PY:
from django import forms
from .models import Language
from django.contrib.auth.models import User
from django.contrib.auth.forms import UserCreationForm
class FreelancerRegistrationForm(forms.Form):
language = forms.ModelChoiceField(queryset=Language.objects.all().order_by('shortcut'))
你知道问题出在哪里吗？ 谢谢
我用这些步骤解决了同样的问题：
- 删除项目目录中的数据库（
db.sqlite3在我的例子中） - 从项目子目录下的
__pycache__文件夹中删除所有内容 - 对于您要修复的应用程序，转到文件夹并清除
migrations和__pycache__目录
当您确定已清除上述所有文件后，运行:
python manage.py makemigrations
python manage.py migrate
希望对您有所帮助。
另一种情况会产生 没有这样的 table 错误。如果您的 views.py 或类似执行的代码在导入时尝试访问数据库，即导入 views.py 有副作用，那么 从头开始将行不通 。
当您的代码使用现有数据库时会发生这种情况，而现在您试图在没有数据库的情况下开始。只需更改 views.py 即可导入而不会产生副作用。如果您不想修复设计，请执行以下操作：
from django.db.utils import OperationalError
format_list = [('', '(all)')]
geom_type_list = [('', '(all)')]
try:
format_list.extend([(i[0],i[0])
for i in Format.objects.values_list('name')])
geom_type_list.extend([(i[0],i[0])
for i in Geom_type.objects.values_list('name')])
except OperationalError:
pass # happens when db doesn't exist yet, views.py should be
# importable without this side effect
添加到 terry_brown 的回答，这就是导致我出现问题的原因。我有一个带有 ForeignKey 的自定义用户模型到另一个模型。我将默认设置为数据库中的第一个对象。当我在数据库中有数据时它起作用了。但是当我从头开始时，它不起作用，因为它在导入时立即执行（所以甚至没有迁移）。
class User(AbstractBaseUser, PermissionsMixin):
subscription_plan = models.ForeignKey(SubscriptionPlan, default=SubscriptionPlan.objects.first().id)
我不得不牺牲 default（将其注释掉）。
更新： 更好的解决方案是使用初始迁移或固定装置预填充您的数据库。
可能没时间了但是...当我尝试 "clone" Django 1.11 安装到其他目录然后初始尝试管理 makemigrations 时我遇到了同样的问题。
我通过以下方式解决问题：
- 通过以下方式设置初始 Django 安装和创建主应用程序：
django-admin.py 启动项目app_name
初始迁移 管理 makemigrations，管理 migrate
设置超级用户：
管理创建超级用户
复制除主目录urls.py和settings.py之外的所有文件和目录（Django应用程序）
已将所有应用程序添加到 INSTALLED_APPS
管理 makemigrations，管理 migrate
从源 Django 应用程序目录复制 settings.py 和 urls.py
就是这样，没有错误，一切正常。
彼得
如果其他人遇到此问题并且接受的解决方案不起作用，请查看您的数据库路径，
数据库路径应该是绝对路径，
'NAME': '/pathto-db/default.db',
运行 命令下方。它解决了我一次这个问题
manage.py 迁移 --运行-syncdb
为了解决这个问题，我这样做了（在 Ubuntu 上，您需要调整 Windows 的命令）：
1.删除所有迁移文件
find . -path "*/migrations/*.py" -not -name "__init__.py" -delete
find . -path "*/migrations/*.pyc" -delete
2。删除 db.sqlite3
rm db.sqlite3
3。创建并 运行 迁移：
python manage.py makemigrations
python manage.py migrate
4.同步数据库：
manage.py migrate --run-syncdb
您需要删除数据库，这有点麻烦，但对于测试系统来说没问题。 从这个普遍优秀的资源中获得了除最后一步之外的所有内容：https://simpleisbetterthancomplex.com/tutorial/2016/07/26/how-to-reset-migrations.html
虽然 运行 任何管理命令 "django.contrib.admin" 会自动尝试发现和 admin.py 已安装应用程序中的模块。
如果有与数据库相关的代码，它会自动运行并尝试从数据库中加载数据，当它在数据库中找不到与 table 相关的数据时抛出此错误。
要修复此错误，只需将 INSTALLED_APPS 中的 "django.contrib.admin" 更改为 "django.contrib.admin.apps.SimpleAdminConfig"，它将阻止 "django.contrib.admin" 自动发现和 运行 管理模块。
django.contrib.admin automatically performs auto discovery of admin modules in installed applications. To prevent it, change your INSTALLED_APPS to contain 'django.contrib.admin.apps.SimpleAdminConfig' instead of 'django.contrib.admin'.
https://docs.djangoproject.com/en/3.0/ref/applications/#troubleshooting
如果上述解决方案的 none 对您有效，则添加 appname 以及 makemigration 和 migrate 命令。
makemigration login
migrate login
这可能会帮助您找出问题所在。
按照以下步骤解决此问题。
python manage.py migrate --fake APPNAME zero
这将使您迁移到假的。现在您可以 运行 迁移脚本
python manage.py migrate APPNAME
或
python manage.py migrate
表将被创建并且您解决了您的问题..干杯！！！
您不需要视图来进行迁移。注释掉 urls.py 中对其他应用程序的所有引用，清除数据库和旧迁移，运行 makemigrations，然后注释掉你的 urls.py。对我有用。
我阅读了其他团队给出的上述答案。 主要是要求删除 SQLite(DB) 并重置“迁移”文件夹。
如果您在生产环境中工作，那么这将不是正确的选择。
python manage.py migrate --fake APPNAME zeropython manage.py migrate APPNAMEpython manage.py makemigrations APPNAMEpython manage.py migrate APPNAME
这四个步骤足以解决这个问题。
我在创建模型时遇到了这个错误。 我打开了 db.sqlite3 文件并使用 SQLite 数据库浏览器为模型创建了一个 table。然后我创建了一个迁移并假迁移了它。不知道是什么原因导致了这个问题，但这个解决方法有所帮助。
我遇到了同样的问题。 None 以上解决方案对我有用。 当我添加一个新模型，数据库中有一些对象，然后我更改了模型名称时，这一切可能都开始了。 我需要从我的应用程序中删除整个模型，然后 运行 应用程序的管理页面。然后我通过在我删除它的所有文件中单击 ctrl + z 来恢复模型，最后我能够 运行 makemigrations 和迁移命令。
你会删除生产银行吗？ 我看到很多都删除了sqlite，但是如果是生产行呢？
从 django_migrations table less contenttypes
中删除数据的解决方案已经在tabledjango_content_type你远程app_label
在 migrations 文件夹中删除除 init.py
之外的所有内容python manage.py makemigrations
python manage.py 迁移 --fake
这就是我解决应用程序重复问题的方法（安装插件后我有两个同名的应用程序）并且 django 创建了丢失的 tables，等等。
在我的正常功能情况下
我遇到了同样的错误。我用来解决这个问题的步骤是：
确保您的应用中有
migrations文件夹。如果没有，在app文件夹中创建migrations文件夹，然后在文件夹中创建__init__.py文件。如果
migrations文件夹已经存在，则删除所有migration files。删除默认为
db.sqlite3的数据库文件。运行命令
python manage.py makemigrationspython manage.py migrate
修复我的错误的唯一方法是注释掉每个 单个文件。当文件认为数据库不为空或实际存在时，可能会发生此错误。
我刚刚注释掉整个项目，迁移，取消注释 models.py 文件，再次迁移，取消注释整个项目。我不知道它为什么起作用。
同样的错误并且没有删除数据库：
- 删除迁移
- 移除
__pychache__ python manage.py makemigrations --empty aliaspython manage.py makemigrations aliaspython manage.py migrate alias zero- 再次删除迁移
- 再次删除
__pycache__ python manage.py makemigrationspython manage.py migrate alias zero
其中别名是应用名称。
如果您删除了数据库并立即迁移，就会发生这种情况。
例如，如果您的错误提示没有 table table1 那么
- python manage.py makemigrations
- python manage.py 迁移
- python manage.py table1 app1
这里table1是table的名字，app1是table1 模型所在的 Django 应用名称。
使用 Django，我必须执行：
python manage.py migrate --run-syncdb
这个错误是因为Django的数据库导致的，这不是用户的错。它最简单的解决方案是使用不同的名称创建新的app。然后创建相同的模型然后运行pythonmanage.pymakemigrations 然后迁移。通过这样做你的错误应该得到解决
我知道这通常是通过删除开发过程中使用的 de sqlite3 数据库来解决的。
另外，我知道这个问题目前已经解决了，但我想把我的案例留在这里作为替代方案。
有时我们在编程时会更改模型中的很多东西。当我们 运行 python manage.py makemigrations 时，会在 app folder/migrations 中创建一个文件。当我们 运行 python manage.py migrate 在 table django_migrations 中创建一条记录。此记录包含 3 个字段，我们必须详细检查：
1 - 名称（这是在迁移应用程序文件夹中创建的文件名）
2 - 应用程序（这是我们应用程序的名称。也像命名空间一样工作以防止冲突）
3 - 已应用（这是执行迁移的日期时间）。
如果你以前修改过你的模型，你应该在迁移中有几个文件（数量与你在每次更改时执行 makemigrations 的时间相应），在我的例子中我想删除这些文件只是为了拥有一个迁移文件。
问题在于，当 makemigrations 再次 运行 时，它会创建一个文件 0001_initial.py。如果您还记得 table django_migrations 包含此文件的日志，这是为了防止执行迁移已经完成了。
如果是这种情况，您将从此 table.
中删除您的应用程序迁移记录我对我的数据库做了一些改动，但遇到了同样的问题。 None 的解决方案对我有用，所以在花了几个小时后，我最终决定删除“db.sqlite3”文件并运行 makemigrations 和 migrate 命令。工作正常后。但是这个解决方案不是立即使用的好方法，只有在您没有选择时才使用它。
我遇到了同样的问题。我删除了所有迁移和 运行 这个命令
python manage.py makemigrations
python manage.py migrate --run-syncdb
它对我有用，数据也很安全（我没有丢失任何数据）