【问题标题】:Edit database outside Django ORM在 Django ORM 之外编辑数据库
【发布时间】:2016-02-08 15:31:56
【问题描述】:

如果使用 Django,那么通过 pgadmin 或 psql 直接对数据库(在我的情况下为 postgres)进行的更改会发生什么?

迁移如何处理此类更改?它们是否优先于 ORM 认为的事态,还是 Django 会覆盖它们并强加它自己的变更历史感?

最后,如果有的话,git 是如何影响或避免这些问题的?

谢谢。

【问题讨论】:

  • 您指的是架构还是数据更改?
  • 架构,但也许我应该同时询问这两个问题?

标签: python django git postgresql


【解决方案1】:

您可以从 django 迁移中完全排除模型,然后您负责将架构调整为 django 代码(或将 django 代码调整为现有架构):

class SomeModel(models.Model):

    class Meta:
        managed = False  
        db_table = "some_table_name"   

    name = models.Fields....

请注意,您不能同时拥有这两种方式,因此尽可能首选迁移。您始终可以定义自定义 SQL 迁移,这将节省外部更改的需要。但是,有时您确实需要在其他地方处理架构而不是迁移,然后使用 managed=False

【讨论】:

    【解决方案2】:

    迁移系统根本不会查看您当前的架构。它从以前的迁移图和 models.py 的当前状态构建它的图片。这意味着如果您从该系统外部更改模式,它将不同步;如果您随后在 models.py 中进行等效更改并创建迁移,则在运行它们时可能会出错。

    因此,您应该避免这样做。如果它已经完成,您可以在假模式下应用冲突迁移,这只是将其标记为已完成,而无需实际针对数据库运行代码。但是首先通过迁移来完成所有事情会更简单。

    git 对此完全没有影响,只是重申迁移是代码,应该添加到您的 git 存储库中。

    【讨论】:

    • 实际上,这两个答案都有帮助,但我选择了 Aviah,因为如果您要摆脱的迁移是来自 psql/pgadmin 的迁移,那么虚假迁移并不能解决问题。
    猜你喜欢
    • 2018-01-17
    • 1970-01-01
    • 2011-01-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多