Python 创建或更改PostgreSQL表以确保Django模型匹配

今天，在Django项目的开发过程中，我遇到了一个恼人的问题，当时我正试图在测试数据库和开发数据库之间切换，而我似乎无法找到解决迁移问题的可靠方法

让我们调用我的“测试”数据库：testDB和我的“开发”数据库：devDB

我像往常一样通过Django settings.py访问testDB，并进行了迁移，添加了您在下面代码中看到的clientID字段

然后，我决定切换到Django的settings.py中的devDB来运行python manage.py migrate，并且我的clientID字段不会添加到新的数据库中。当我运行python manage.py makemigrations时，正如预期的那样，“未检测到任何更改”

请注意，我在进行迁移后使用PyPi中的django reset migrations包，这样migrations文件夹就不会变得复杂，所有内容都存储在一个0001_initial.py migrations文件中

我没有看到比编写我自己的脚本更好的方法来处理这个问题，该脚本确保所有模型表都存在于我连接到的任何数据库中，并且所有模型字段都位于每个表中，否则会更改表并添加相应的列，这就引出了我的问题

如果我使用：python manage.py sqlmigrate objects 0001（这是我的0001_initial.py文件），我将看到以下创建代码：

CREATE TABLE "objects_users" (
    "id" serial NOT NULL PRIMARY KEY, 
    "clientID" integer NOT NULL, 
    "email" varchar(100) NOT NULL, 
    "first_name" varchar(100) NOT NULL, 
    "last_name" varchar(100) NOT NULL, 
    "phone" varchar(100) NOT NULL, 
    "password" varchar(100) NOT NULL, 
    "type" varchar(100) NOT NULL, 
    "date_created" timestamp with time zone NOT NULL, 
    "active" varchar(100) NOT NULL);

我如何使用这个创建语句并循环包含的字段，以确保它们在我连接的数据库中可用（我认为使用alter语句是最好的方法）

大音符

我只与Django合作了几个月，但我记得Django的文档中说，通常最好将attriubutenull=true添加到addedModel.fields中，以便在发生迁移时自动将其添加到数据库中。我不确定这在我的实例中是否是一个问题，我只是试图找到一个解决方案，自动确保无论我连接到哪个数据库，我都完全同步，并且没有SQL错误表明字段不存在，即使在我运行迁移时也是如此

到目前为止，我已经能够解决我的问题，清除连接到的任何数据库，然后根据初始迁移文件运行python manage.py migrate，但对于无法重置所有内容的生产实例，这不是一个有效的解决方案

我需要一些想法，我认为基于我从

python manage.py sqlmigrate objects 0001

获得的字符串的alter table语句是目前为止最好的，但我愿意接受任何可以解决我的问题的方法，所以我不必再担心这个问题。请注意，在进行迁移之后，我使用PyPi的django reset migrations软件包，因此迁移文件夹不会变得复杂，所有内容都存储在一个0001_initial.py迁移文件中。

解决问题的方法很简单：停止这样做

以这种方式重置迁移文件是一种先进的、潜在危险的技术。它从来都不是必需的，但在某些情况下可能会有所帮助。migrations文件夹“变得复杂”不是一个真正需要解决的问题，尤其是对于一个刚开始的项目

---

危险的是，通过设计，它正在擦除对模型和数据库所做更改的历史记录。因此，如果您在数据库没有完全更新时运行它，显然您已经删除了执行此操作所需的信息。（特别是，在迁移dev数据库之前重置迁移时，删除了指定如何添加新列的文件。）

这很有意义。我倾向于将此标记为正确的，但现在让我测试一下不重置迁移和移动数据库连接，看看是否遇到问题。我很清楚，您是说如果我不处理迁移文件（即不重置它们），我将能够切换数据库，运行manage.py migrate，并且无论新数据库中的表是否存在，它都将正确同步本质上说，不使用django重置迁移是最好的选择。@ViaTech:是的。事实上，这是移民的主要目的。请注意，此建议不会解决现有的数据库问题。您表示愿意从头开始，所以这样做，以后您就不会有这个问题。是的，我认为只要我保持迁移的技巧，这将解决我的问题。太好了，谢谢！你能描述一下重置迁移的“好情况”吗？我知道这是为了将来参考？@ViaTech：大量迁移的主要缺点是它会降低测试速度，因为测试数据库每次都是从头开始构建的（除非你使用

--keepdb

）。这是一个经常被引用的动机。请注意，Django有一个内置的、更安全的、不太全面的版本。太好了，今天晚些时候我有机会了解Django的迁移压缩，谢谢！