问题标签 [django-south]

我想向现有模型添加一列，并且在运行“schemamigration --auto”后，生成的迁移尝试删除另一个表！为什么会这样做？

我的模型（简化）-

结果迁移——

我想知道在项目的大量初始开发过程中使用 (django) South 的优势。

在开发的早期阶段，通常会发生快速的模型更改、频繁的分支和合并（尤其是如果您使用像 git-flow 这样的开发策略）并且存储的数据非常少（如果有的话）。为什么要保留这些初始模型更改？有什么优点/缺点？

我的印象是，在激活 South 并执行初始迁移之前，等待开发稳定下来（并且您拥有实际想要保留的数据）更容易。有可能这样做吗？你想这样做吗？

我们正在将 Django 项目的几个实例中的数据迁移到新模式。

旧模式有：

新架构具有：

我们正在尝试使用 South 为这些组和用户进行数据迁移。http://south.aeracode.org/docs/tutorial/part3.html

我已经收集到我需要使用转发规则来指定如何迁移用户，但是我遇到了一些问题。

主要问题是如果我要创建一个扩展 AccessEntity 类的新用户对象，如何保持用户/组的 ID 相同。

用户和组由他们拥有或分配给他们的对象引用。如果我更改他们的 ID，则该信息将丢失。即使我现在需要从 AccessEntity 扩展对象，有没有办法为对象保留相同的 ID？

我试图简单地部署我们的应用程序并更轻松地管理我们所依赖的库和框架的版本。

在我们的 VCS 中存储 Django 有意义吗？理想情况下，这将使我更容易简化部署，并且我可以使用 South 管理 Django 对内置应用程序（django.contrib.auth、django.contrib.sites 等）所做的任何模型更改。

我有理由不这样做吗？你为你的应用做了什么？

我们正在使用旧版本的 Django (1.1.1)，并准备尽快升级到最新版本（当前为 1.2）。

我的搜索都没有提出跨 Django 版本迁移数据库表（auth_user 等）的主题。使用 syncdb 仅适用于创建新表，但对现有表没有影响。

我的印象是升级不仅仅是链接到新版本的 Django 文件，而且我们还需要管理数据库的迁移，因为我们依赖于一些内置的 Django 应用程序（django.contrib.auth， django.contrib.sites 等）。我们计划使用 South 来管理数据库迁移。

这是 Django 在内部处理的吗？我是否试图解决一个不存在的问题？

我正在将现有的代码库（带有多个应用程序）转换为使用 South。我的代码库目前安装在 1 台开发服务器和 3 台生产服务器上。开发有自己的数据库，3台生产服务器都连接到一个中央数据库。

我在http://south.aeracode.org/docs/convertinganapp.html阅读了信息，但我仍然对如何继续感到有些困惑。

这是我计划遵循的步骤：（
Dev Server: ./manage.py syncdb在 dev db 中创建 South 表）
Dev Server: ./manage.py convert_to_south myapp（在 dev db 中创建 South 文件和记录）
Dev Server: push to VCS

Server 1: pull from VCS（获取 South 文件）
Server 1: ./manage.py syncdb（在生产数据库中创建 South 表）
Server 1: ./manage.py migrate myapp 0001 --fake（在生产数据库中创建 South 记录）

Server 2: pull from VCS (To get South files)
Server 2: ./manage.py migrate myapp 0001 --fake

Server 3: pull from VCS (To get South files)
Server 3: ./manage.py migrate myapp 0001 --fake

对所有应用重复这些步骤。

问题 1：
服务器 2 和 3 是否需要执行 此./manage.py migrate myapp 0001 --fake步骤？由于我将在服务器 1 上运行迁移，并且所有三台服务器都使用相同的数据库，因此似乎不需要它，但我不是 100% 确定。

问题 2：
如果./manage.py migrate myapp 0001 --fake需要在服务器 2 和 3 上执行，是否每次进行数据库迁移时都需要在服务器 2 和 3 上运行该命令？

一如既往，非常感谢您的帮助。

我正在使用一个遗留数据库，它以 db 方式做了一些有意义的事情，但不确定如何在 Django 中表示它们，以便 South 和 Django 本身可以处理它们。

我有一个 PartCode 作为键的零件表 我有一个 VendorCode 作为键的供应商表

我有一个 PartsVendor 表，其中包含 FK 到 Parts 和 Vendor，以及有关关系的其他信息。我使用的是“through”参数，所以它独立存在，但它使用 PartCode+VendorCode 作为复合键，Django 不支持。只有在使用 South 或像 dumpdata 这样它想查看主键的函数时，我才会遇到问题。然而，这些都是相当大的问题。

我的临时解决方案是只添加一个 _id 字段作为 AutoField 并在 Postgres 中添加一个串行字段，它工作正常，但是当使用 South 时，它会因默认 = False 而 NOT NULL 为真这一事实而窒息。

我已经走上了尝试编写自定义字段的道路，但这似乎是一条死胡同，因为我实际上并没有更改有关字段类型的任何内容。

我有auth以模型命名的现有应用程序，并将数据库与表同步。我south在项目设置中安装，运行./manage.py convert_to_south auth. 它成功创建并应用了虚假迁移。然后我在这个应用程序中添加新模型并运行./manage.py schemamigration auth --auto。当我试图通过运行迁移它时，./manage.py migrate auto它给了我这个巨大的错误：

有任何想法吗？

我遇到了一个问题，South 在我迁移时为新模型创建数据库表为 INNODB，但在另一个开发人员运行自己的迁移时创建表为 MISAM。

问题在于我所有的其他表都是 MISAM，因此使用新表会导致许多外键约束错误。

如何明确确保表是使用 MISAM 创建的？

什么可能导致在不同环境中使用不同的存储引擎创建表？

在 Django-South：我改变了我已经成功地为 myapp 运行了初始迁移，但是由于某种原因，在我对模型进行了更改并转到

而且我得到了很多回溯，这些回溯以：

经过多次谷歌搜索，我发现并尝试了这个：

然后我继续迁移它，但无济于事；同样的错误。

有什么建议么？