在现有Django应用中更改主键的最佳方法是什么?
我有一个处于测试版模式的应用程序。此应用程序的模型具有一些带有显式primary_key的类。因此,Django使用字段并且不会自动创建ID。
class Something(models.Model): name = models.CharField(max_length=64, primary_key=True)
我认为这是个坏主意(在django admin中保存对象时,请参见unicode错误),我想回过头来为模型的每个类提供一个ID。
class Something(models.Model): name = models.CharField(max_length=64, db_index=True)
我已经对模型进行了更改(将每个primary_key = True替换为db_index = True),并且我想使用south迁移数据库。
不幸的是,迁移失败并显示以下消息: ValueError: You cannot add a null=False column without a default value.
我正在评估此问题的不同解决方法。有什么建议?
回答:
正式主键应始终是代理键。没别的 [强词。自1980年代以来一直是数据库设计师。得到的重要经验教训是:一切都是可变的,即使用户在母亲的坟墓上发誓无法改变价值,这确实是可以作为首要的自然钥匙。它不是主要的。只有代理人可以是主要的。]
你正在做心脏直视手术。不要搞乱架构迁移。你正在替换架构。
- 将数据卸载到JSON文件中。为此,请使用Django自己的内部django-admin.py工具。你应该为每个将要更改的文件以及每个依赖于所创建键的表创建一个卸载文件。单独的文件使此操作更加容易。
- 从旧模式中删除要更改的表。
- 依赖于这些表的表将更改其FK。你可以就地更新这些行,或者-可能更简单-删除并重新插入这些行。
- 创建新的架构。这只会创建正在更改的表。
- 编写脚本以读取新密钥并重新加载数据。这些很短而且非常相似。每个脚本将用于json.load()从源文件读取对象;然后,你将根据为你构建的JSON元组线对象创建模式对象。然后,你可以将它们插入数据库。
你有两种情况。
- PK更改已更改的表将被插入并获得新的PK。这些必须“级联”到其他表,以确保其他表的FK也被更改。
- 具有更改的FK的表必须在外部表中找到该行并更新其FK参考。
另类。
- 重命名所有旧表。
- 创建整个新架构。
- 编写SQL,将所有数据从旧模式迁移到新模式。这将不得不巧妙地重新分配密钥。
- 删除重命名的旧表。
以上是 在现有Django应用中更改主键的最佳方法是什么? 的全部内容, 来源链接: utcz.com/qa/432575.html