为什么在最初开发时使用南方？
我想知道在项目的繁重初始开发过程中使用 (django) South 的优势。
在开发的早期阶段，通常会出现快速的模型更改、频繁的分支和合并（特别是如果您使用像 git-flow 这样的开发策略），并且存储的数据（如果有的话）很少。您为什么要保留这些初始模型更改？有什么优点/缺点？
我的印象是，等到开发稳定下来（并且您拥有真正想要保留的数据）后再激活南方并执行初始迁移会更容易。可以这样做吗？你愿意这样做吗？
I'm wondering about the advantages of using (django) South during heavy initial development of a project.
At the early stages of development there's normally rapid model changing, frequent branching and merging (especially if you use a development strategy like git-flow) and very little, if any, stored data. Why would you want to keep of these initial model changes? What are the advantages/disadvantages?
I'm under the impression that it's easier to wait until the development settles down (and you have data you actually want to keep) before activating South and performing an initial migration. Is it possible to do that? Would you want to do that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
一旦我要推送其他人需要使用的提交，我就会创建一个迁移，以便他们仍然可以拥有工作副本。
如果您单独工作（并且不担心部署），这不是问题，您可以等到最后一刻来创建迁移。
一旦您开始与其他人合作，快速迁移就会变得更加容易，因此它成为一种工作流程习惯，并且每个人都在同一数据库页面上。
此外，如果您只是修改字段，则不可以使用syncdb。仅仅为了添加、删除或修改字段就必须删除一个表，这是非常烦人的。
如果我添加了一堆架构迁移，有时我会将它们组合（回滚并删除它们并创建新的巨型迁移）到单个迁移中。但通常情况下，迁移的次数并不会困扰我，因为它们实际上并没有花费我任何钱。
As soon as I am about push a commit that other people need to use, I create a migration so they can still have a working copy.
If you are working alone(and not worrying about deployment), this is not an issue and you can wait until the last possible moment to create a migration.
Once you begin working with others, it makes life easier to quickly make migrations so it becomes a workflow habit and everyone is on the same database page.
Also, syncdb is not an option if you are simply modifying a field. It gets incredibly annoying to have to blow away a table just for adding, deleting or modifying fields.
If I have a bunch of schema migrations that I added, sometimes I will combine them(rollback and delete them and create a new jumbo migration) into a single migration. But normally, the number of migrations doesn't bother me because they don't cost me anything really.
我发现 South 在开发过程中和开发后一样有用，正是因为表字段经常更改。为了添加一个字段而必须删除一个表并使用syncdb重新创建它是非常烦人的，特别是如果您有任何测试数据的话。 （您也可以直接在 DBMS 中修改表，但是您必须小心使用 Django 期望的相同字段类型，适当设置 ON DELETE 等属性等）。另外，如果其他人正在处理该项目，您必须确保告诉他们对其数据库副本进行完全相同的更改。在我看来，南方让事情变得简单得多。
话虽这么说，如果 South 可以选择删除所有以前的迁移，那可能会很酷，这样当您完成初始开发并开始添加真实数据时，就可以从头开始。但最终，这十几个额外的迁移文件并不会真正花费您任何费用。
I've found South to be just as useful during development as afterwards, precisely because the table fields are changing so often. It's pretty annoying to have to drop a table and re-create it with syncdb just to add one field, especially if you have any test data at all. (You could also just modify the table directly in your DBMS, but then you have to be careful to use the same field type that Django is expecting, set the attributes like ON DELETE appropriately, etc.). Plus if anyone else is working on the project, you have to make sure to tell them to make exactly the same changes to their copy of the database. South makes it much simpler, IMO.
That being said, it might be cool if South had an option to delete all previous migrations, so you could start with a clean slate when you're wrapping up the initial dev and starting to add real data. But ultimately those dozen or so extra migration files aren't really costing you anything.
在最初的开发过程中我没有使用 South。我只有 一个脚本 为每个应用程序创建固定装置，因此当架构更改时，我转储旧的测试数据，编辑架构，更新测试数据，使其适用于新架构，然后恢复数据。
I don't use South during the initial development. I just have a script which creates fixtures for each app, so when the schema changes, I dump the old testing data, edit the schema, update the testing data so that it will work with the new schema, then restore the data.
从某个阶段开始，肯定可以利用南方进行初始迁移。 South 文档在这里： http://south.aeracode.org/docs /tutorial/part1.html#converting-existing-apps
我在开发过程中确实使用了 South，因为我经常有数据用来测试 UI 或类似的东西。如果您在每次模型更改后不从全新的数据库开始，South 对于保持数据库的一致性也非常有帮助。因此，我也同意 meder 的观点，如果 Django 能够进行模式迁移，那就太好了，另一方面，这并不重要，因为 South 很容易实现。
It definitely is possible to use south from a certain stage on and do an initial migration. SOuth docs here: http://south.aeracode.org/docs/tutorial/part1.html#converting-existing-apps
I do use south during development, as i often have data that i use to test the UI or such things. South is also very helpful in keeping your database consistent if you do not start with a complete new database after every model change. Therefor i agree with meder too, it would be great if Django would have that schema migration, on the other hand it doesn't matter that much as south is very easy to implement.
好消息 - 自 2014 年 9 月 2 日起，迁移现已成为核心 Django 1.7 版本的一部分。
https://docs.djangoproject.com/en/dev/releases/1.7/
我正要安装 South，现在不需要了。希望这能为处于相同情况的其他用户提供有用的提示。
Good news - as of 2nd September 2014 migrations are now part of core Django, release 1.7.
https://docs.djangoproject.com/en/dev/releases/1.7/
I was just about to install South, and now I don't have to. Hope this gives a useful heads-up to other users in the same situation.