我删除了一个与应用相关的表格。并再次尝试了syncdb命令
python manage.py syncdb
显示错误,如
django.db.utils.ProgrammingError: (1146, "Table 'someapp.feed' doesn't exist")
models.py
class feed(models.Model):
user = models.ForeignKey(User,null=True,blank=True)
feed_text = models.CharField(max_length=2000)
date = models.CharField(max_length=30)
upvote = models.IntegerField(default=0)
downvote = models.IntegerField(default=0)
def __str__(self):
return feed.content
我可以做些什么来获取该应用的表格?
答案 0 :(得分:69)
如果django版本> = 1.7:
python manage.py makemigrations
python manage.py migrate --fake
否则
python manage.py schemamigration someapp --auto
python manage.py migrate someapp --fake
答案 1 :(得分:11)
对于那些可能仍有问题的人(比如我),请试试这个:
注释掉主应用urls.py
然后继续运行迁移:
$ ./manage.py makemigrations
$ ./manage.py migrate
删除()
的
solved_time = models.DateTimeField('solved time', default=timezone.now())
到
solved_time = models.DateTimeField('solved time', default=timezone.now)
答案 2 :(得分:2)
我只是运行了附加应用名称的迁移,适用于我已配置且有效的所有应用。
例如python3 manage.py makemigrations my_custom_app
在为所有这些人运行后,我运行了一个迁移命令来达成交易。
python3 manage.py migrate
。就是这样。我仍然想知道为什么 django 有时会这样。
答案 3 :(得分:1)
以上解决方案都没有为我工作,我终于通过
解决了sudo systemctl stop mysql.service
sudo apt-get purge mysql-server
sudo apt-get install mysql-server
sudo systemctl stop mysql.service
在我的情况下,我提取的代码有managed = False,我希望表格由Django维护。
但是当我做了makemigrations时,没有检测到自定义表,或者我收到 app_name.Table_name 不存在的错误
我尝试了以下内容:
PS:此解决方案仅在存在备份或数据不重要或您刚刚开始创建表时才可行,因为清除mysql会导致数据丢失
答案 4 :(得分:1)
据我所知,这链接到项目内部脚本中的迁移数据与数据库中的迁移脚本不匹配。 我通过以下步骤解决了这个问题:
__ini__
以外的所有迁移文件夹下的迁移脚本managed=True
$ ./manage.py makemigrations
$ ./manage.py migrate
这将再次创建迁移脚本并将其应用于您的数据库。
答案 5 :(得分:0)
我遇到了这个问题,我在生产和开发中都使用相同的数据库结构。虽然删除和重新创建表可能会解决问题,但值得检查数据库本身并查看模型是否正确。对于我自己,我错误地创建了开发数据库,并且表名全都用小写字母,而在生产中,表的首字母大写。我在生产db上使用了python manage.py inspectdb命令,并将其与模型进行比较,并意识到在模型中,它试图将数据插入表“ test”而不是“ test”。希望以后对您有所帮助。
答案 6 :(得分:0)
我必须面对同样的问题,有两种方法,但是我认为是最可能的方法。
也许您正在将视图或查询加载到数据库,但是您没有给Django足够的时间来将模型迁移到DB。这就是为什么“表不存在”的原因。
确保在视图的代码中使用这种初始化:
RegisterForm(forms.Form)类
def __init__(self, *args, **kwargs):
super(RegisterForm, self).__init__(*args, **kwargs)
第二种方法是清理先前的迁移,删除数据库并重新开始迁移过程。
答案 7 :(得分:0)
我尝试了所有上述技巧,但从未为我工作。 我对所有调用特定表的导入和URL进行了评论
答案 8 :(得分:0)
在manage.py setmigration然后迁移到SQL数据库不能正常工作的情况下,解决了我的问题的原因如下:
python manage.py migrate --fake MyApp zero
python manage.py migrate MyApp
并且connections.py以及在正确运行迁移命令后出现的问题得到解决!至少对我来说。
我正在使用Python(3.x),MySQL DB,Django(3.x),并且在一段时间后需要在数据库中成功创建表的情况下,遇到一些关于connections.py的错误加薪。但是,上述命令有所帮助。我希望他们能帮助所有遇到此类问题的人。
答案 9 :(得分:0)
如果 python manage.py migrate 仍然不起作用我的意思是当你这样做时它什么都不做你可以在之后从 django_migrations 表中删除应用程序的迁移
python manage.py migrate
答案 10 :(得分:0)
我遇到了类似的问题。
我有另一个需要访问 DB 的 python(带有类)文件。
出于某些原因,当运行“makemigrations”时,该文件被处理(我猜这与某些导入链有关)。
在这个类中,我有一个在签名中包含默认参数 method(defaultModel=Model.get_default())
的方法,该方法访问数据库中的默认对象(模型类中包含的静态方法)。
A 导入时间,已评估此默认参数,但由于表尚未填充,因此出现此错误。
所以我只是为默认参数设置了 None
并要求方法内的默认模型对象。这解决了问题。