【问题标题】:Foreign key migration using django south使用 django south 进行外键迁移
【发布时间】:2012-04-11 08:57:25
【问题描述】:

我更改了外键的引用而没有更改字段的名称,现在我在同一个字段上有 2 个约束指向不同的表。 我的模型是这样的

class Activity(models.Model):
    ...
    source = models.ForeignKey(FSObject)

变成了

class Activity(models.Model):
    ...
    source = models.ForeignKey(FreezedRef)

现在我在运行测试时收到此消息:

IntegrityError: (1452, 'Cannot add or update a child row: a foreign key constraint fails (`test_tcf_api`.`storage_activity`, CONSTRAINT `source_id_refs_id_fc96b4b044ceb88` FOREIGN KEY (`source_id`) REFERENCES `storage_fsobject` (`id`))')

我应该如何删除这个旧参考,显然,South 跳过了它。

【问题讨论】:

    标签: python mysql django django-south


    【解决方案1】:

    您是否在同一迁移中更新了其他任何内容?他们工作还是休息?我之所以这么问,是因为我从来没有让 South 在运行迁移时破坏任何东西 - 如果出现问题,它通常会在该过程中引发异常。

    【讨论】:

    • 他很可能正在处理 mysql 中的一个特质。我之前遇到过这个问题,一个表是 myISAM,另一个是 InnoDB。 South/django 创建的约束当然会失败,因为 myISAM 不支持外键。不确定到底如何走上这条路,但我以前见过确切的问题。
    • 因此我的第一个建议是放弃垃圾数据库并转移到不那么糟糕的东西上。这只是使用 mysql 的众多问题之一
    【解决方案2】:
    1. 停止使用像 MySQL 这样的糟糕数据库,因为它们只是一个有点像数据库的东西(抱歉无法抗拒,但这是真的)
    2. ALTER TABLE tbl_name DROP FOREIGN KEY fk_symbol; 直接来自 mysql 文档:http://dev.mysql.com/doc/refman/5.5/en/innodb-foreign-key-constraints.html

    【讨论】:

    • 为什么你认为 MySQL 不好?
    • 默认情况下,它与远程 ACID 不兼容,这种方式真的很糟糕,没有 ForeignKey 约束,没有事务,无法索引超过 1k 的字段(你可以说这无论如何都是糟糕的设计,但这仍然只是 300ish unicode 字符),无法索引函数结果,没有实现 EXPLAIN ANALYZE,在模式更改命令期间没有事务,查询每个表的每个查询只使用一个索引(强制使用大量多列索引而不是动态组合索引) .如果我花一些时间,我相信我可以想得更多,基本上我每周都会发现新的东西
    • 显然我意识到 innodb 可以帮助其中的几个(没有 fk 和没有事务),大多数不能,但有些可以。 InnoDB 应该是默认设置,如果你想快速轻松地获得一点性能,你应该换成 MyISAM,而不是相反。 MySQL IMO 唯一真正好的地方是它是第一个被广泛采用的开源数据库,并为网络提供了很多选择。 PHP 也有类似的说法,我认为没有多少人会争辩说 PHP 很棒或最好的工具。
    猜你喜欢
    • 1970-01-01
    • 2017-06-26
    • 2011-08-14
    • 1970-01-01
    • 2012-08-06
    • 2012-08-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多