【问题标题】:Django : Table doesn't existDjango:表不存在
【发布时间】:2015-02-19 10:25:02
【问题描述】:

我删除了一些与应用相关的表格。并再次尝试了 syncdb 命令

python manage.py syncdb

它显示像

这样的错误
django.db.utils.ProgrammingError: (1146, "Table 'someapp.feed' doesn't exist")

模型.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

我可以做些什么来获取该应用程序的表格?

【问题讨论】:

    标签: python mysql django django-models


    【解决方案1】:
    1. 删除表(你已经这样做了),
    2. 在model.py中注释掉模型,
    3. 和..

    如果 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. 在models.py中注释你的模型
    2. 转到第 3 步。这次没有 --fake

    【讨论】:

    • 问题是,模型被注释掉后,其余代码有错误……
    • @HarshaBiyani 当然,您需要在短时间内关闭导入,直到您再次评论模型
    • 谢谢!!!我有一个问题,它没有在生产中将表添加到我的数据库中。花了几个小时试图通过删除迁移来修复它。但是,只是伪造迁移并重新添加模型即可解决问题。 Django 1.10
    • 谢谢。但真正的问题仍然存在……为什么会发生这种情况?
    • 这个解决方案不起作用,因为有用户模型,如果我评论它,那么 Django 会失败。无法评论整个项目和整个 Django 代码。
    【解决方案2】:

    对于那些可能仍然有问题的人(比如我),试试这个:

    注释掉主应用urls.py中的所有URL

    然后继续运行迁移:

    $ ./manage.py makemigrations
    $ ./manage.py migrate
    

    删除()'s 后问题得到缓解

        solved_time = models.DateTimeField('solved time', default=timezone.now())
    

        solved_time = models.DateTimeField('solved time', default=timezone.now)
    

    I got this answer from reddit

    【讨论】:

      【解决方案3】:

      在manage.py setmigration然后迁移到SQL数据库无法正常工作的情况下解决我的问题的方法如下:

      1. 运行命令:python manage.py migrate --fake MyApp zero
      2. 之后:python manage.py migrate MyApp

      connections.py 和正确运行迁移命令后出现的问题解决了!至少对我来说。

      我正在使用 Python (3.x)、MySQL DB、Django (3.x),在我的数据库中成功创建表一段时间后,我遇到了一些关于connections.py 的错误提高。但是,上述命令有所帮助。我希望他们能帮助所有遇到此类问题的人。

      【讨论】:

        【解决方案4】:

        我刚刚运行了带有附加应用名称的迁移,对于我已配置的所有应用程序并且有效。

        例如python3 manage.py makemigrations my_custom_app

        在为所有这些运行后,我运行了一个迁移命令来达成交易。 python3 manage.py migrate。就是这样。我仍然想知道为什么 django 有时会这样。

        【讨论】:

          【解决方案5】:

          以上解决方案都不适合我,我终于解决了

          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 维护。

          但是当我进行迁移时,自定义表没有被检测到,或者我收到 app_name.Table_name 不存在的错误

          我尝试了以下方法:

          1. 删除迁移文件夹中的所有迁移文件(init.py 文件除外)然后 makemigrations 最后迁移
          2. 以上 2 个答案
          3. this

          PS:此解决方案仅在存在备份或数据不重要或您刚刚开始创建表时才可行,因为清除 mysql 会导致数据丢失

          【讨论】:

            【解决方案6】:

            据我所知,这与项目内脚本中的迁移数据相关联,与数据库中的迁移脚本不匹配。 我通过以下步骤解决了这个问题:

            1. 删除迁移文件夹下除__ini__之外的所有迁移脚本
            2. 确保model.py包含与数据库中的表相同的结构和managed=True
            3. 删除所有 Django 创建的表,如 auth_user,...等
            4. 运行以下代码
            $ ./manage.py makemigrations
            $ ./manage.py migrate
            

            这将再次创建迁移脚本并将其应用于您的数据库。

            【讨论】:

              【解决方案7】:

              我在生产和开发中使用相同的数据库结构时遇到了这个问题。虽然删除和重新创建表可能会解决问题,但值得检查您的数据库本身并查看 model 是否真的正确。对于我自己,我错误地创建了开发数据库,​​表名全部小写,而在生产中,表的第一个字母大写。我在生产数据库上使用了python manage.py inspectdb 命令,并将其与model 进行了比较,并意识到在模型中它试图将数据插入表'test'而不是'Test'。希望对你们中的一些人有所帮助。

              【讨论】:

                【解决方案8】:

                我必须面对同样的问题,有几种方法,但我认为最有可能的一种。

                也许您正在将视图或查询加载到数据库,但您没有给 Django 足够的时间将模型迁移到数据库。这就是“表不存在”的原因。

                确保在视图代码中使用这种初始化:

                类RegisterForm(forms.Form):

                  def __init__(self, *args, **kwargs):
                    super(RegisterForm, self).__init__(*args, **kwargs)
                

                第二种方法是清理以前的迁移,删除数据库并重新开始迁移过程。

                【讨论】:

                  【解决方案9】:

                  我尝试了上述所有技巧,但从未对我有用。 我评论了所有调用特定表的导入和 URL

                  【讨论】:

                    【解决方案10】:

                    我也有类似的问题。

                    我有另一个需要访问 DB 的 python(带有类)文件。

                    由于某些原因,在运行“makemigrations”时,此文件已被处理(我猜这与某些导入链相关联)。

                    在这个类中,我有一个在签名中包含默认参数 method(defaultModel=Model.get_default()) 的方法,该方法正在访问数据库中的默认对象(模型类中包含的静态方法)。

                    A 导入时间,此默认参数已评估,并且由于尚未填充表,因此会出现此错误。

                    所以我只是将None 设置为默认参数,并在方法内询问默认模型对象。这解决了问题。

                    【讨论】:

                      【解决方案11】:

                      在此解决方案中,您的数据将被删除。我删除了该应用程序并再次创建了该应用程序。我将 app 文件夹复制到某处并从我的项目中删除了 app 文件夹。我评论了 urls.py 中的所有行以及使用此应用程序的类似 views.py 和 admin.py 文件。 settings.py 中还有应用名称。

                      在mysql中:

                      truncate django_migrations;
                      truncate django_admin_log;
                      

                      对您应用中的所有模型执行此操作并更改 n. n 是应用 ID。

                      delete from auth_permission where content_type_id=n
                      delete from django_content_type where app_label='appname'
                      
                      python manage.py startapp your_app_name
                      

                      然后取消注释之前的行并恢复文件并运行

                      python manage.py makemigrations
                      python manage.pt migrate
                      

                      【讨论】:

                        【解决方案12】:

                        你可以跑

                        python manage.py makemigrations --skip-checks
                        python manage.py migrate--skip-checks
                        

                        【讨论】:

                          【解决方案13】:

                          如果 python manage.py migrate 仍然不起作用我的意思是当你这样做时它什么都不做你可以从 django_migrations 表中删除应用程序的迁移然后做

                          python manage.py migrate
                          

                          【讨论】:

                            猜你喜欢
                            • 1970-01-01
                            • 2019-09-15
                            • 2015-07-03
                            • 2016-06-14
                            • 2016-12-14
                            • 2018-03-20
                            • 1970-01-01
                            • 2014-05-19
                            相关资源
                            最近更新 更多