在使用Django时,大型网站如何处理即时架构更改?

时间:2010-09-23 17:27:42

标签: django

我一直在使用south但我真的很讨厌不得不再次手动迁移数据,即使我对一个类进行了一次小的itty bitty更新。如果我不使用django,我可以轻松地改变表模式并在课堂上进行调整,我很好。

我知道大多数人可能会告诉我事先正确地想出架构方式,但实际上有时你需要立即做出改变,我不认为使用south是理想的对此。

人们是否使用某种高级方法,甚至可能修改Django本身的核心?或者有些关于south的东西,我不只是在闲聊吗?

1 个答案:

答案 0 :(得分:1)

  

我真的很讨厌不得不再次手动迁移数据,即使我对一个类进行了一次小小的更新。

您能指定哪种更新?如果您的意思是添加新字段或编辑现有字段,那么显然是的。如果您的意思是修改对字段进行操作的方法,则无需迁移。

  

我知道大多数人可能会告诉我要提前正确地考虑架构方式

考虑它几次肯定会有所帮助。经验也有帮助。但显然你无法预见一切。

  

但实际上有时你需要立即做出改变,我不认为使用南方是理想的。

老实说,我不相信这个论点。如果可以使用SQL“立即”部署更改,那么我认为它们也可以使用South进行部署。特别是如果您使用Fabric等自动部署。

此外,我发现很难相信使用生成的脚本执行迁移所花费的时间可能远远大于首次编写适当的SQL然后执行它所花费的时间。至少在我的经验中并非如此。

一个例外可能是ORM不容易具有SQL的等价物的情况。在这种情况下,您仍然可以通过(南)迁移脚本执行原始SQL。

  

或者有什么关于南方的东西,我不仅仅是在闲逛吗?

我怀疑你没有想到有序,版本控制,可逆迁移的想法。仅限SQL的迁移并不总是可逆的(我知道有例外)。除非开发人员特别注意保留它们,否则它们不是有序的。我甚至看到人们在生产中发现潜在的麻烦更新,甚至没有暂停开始事务,然后丢弃SQL甚至没有记录它。

我不是在质疑你的技巧或对细节的关注;我只是指出我认为你与南方的脱节。

希望这会有所帮助。