gpt4 book ai didi

Django South 和约束 ID

转载 作者:行者123 更新时间:2023-11-29 14:00:31 25 4
gpt4 key购买 nike

创建唯一键和外键约束时,South 如何得出约束名称的 ID,例如:

CONSTRAINT report_type_id_refs_id_435782e833badd2f FOREIGN KEY (report_type_id)
REFERENCES reports_reporttype (id) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED,

我一直遇到的问题是迁移试图删除一个约束,但数据库中的实际约束是不同的。

  1. 这个哈希是由 South 自己生成的,还是来自数据库?
  2. 这个散列基于什么?

使用 PostgreSQL 作为数据库。

更新:我注意到不匹配并不是完全随机的。这是数据库的内容:

CONSTRAINT user_id_refs_id_f15cc3cd FOREIGN KEY (user_id)
REFERENCES brandnew4.auth_user (id) MATCH SIMPLE
ON UPDATE NO ACTION ON DELETE NO ACTION DEFERRABLE INITIALLY DEFERRED

这是 South 试图删除的约束:

django.db.utils.DatabaseError: constraint "user_id_refs_id_7e2ccc6bf15cc3cd" of relation "operatorInterface_ospreyuserprofile" does not exist

如果您仔细观察这些约束名称:

        user_id_refs_id_f15cc3cd
user_id_refs_id_7e2ccc6bf15cc3cd

db 中的 8 位十六进制 key 与 South 正在寻找的 16 位 十六进制 key 的最后 8 位相同。

这是怎么回事?


更新 2:我跟踪了生成哈希的位置:https://github.com/django/django/commit/e4ea53677449cfc56a0093bfbd92cb482020bb1e

为什么 South 会在一个迁移中使用 64 位版本的哈希,而在另一个迁移中使用 32 位版本的哈希?

South 版本 0.8.4 - 我在一个全新的空白数据库上运行它。Django 版本 1.4.2

最佳答案

问题是:South 始终在 public 模式中查找约束名称,而迁移是在 public 以外的模式中应用的。因此不匹配。

关于Django South 和约束 ID,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/21054898/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com