Django 1.8迁移与Postgres BDR 9.4.1 [英] Django 1.8 Migration with Postgres BDR 9.4.1

问题描述

我正在使用BDR在Postgres数据库上运行Django迁移。

python manage.py makemigrations

正常运行，但运行

python manage.py migrate

导致以下错误：

ALTER TABLE ... ALTER COLUMN当BDR处于活动状态时，TYPE ...可能仅影响UNLOGGED或TEMPORARY表; auth_permission是一个常规表

违规模块是 django / django / contrib / auth / migrations / 0002_alter_permission_name_max_length.py 。

我没有找到任何关于如何使用Django的UNLOGGED表，特别是因为auth_permissions是一个Django表（不是由我创建的） 。我也不知道UNLOGGED表是否会复制。

有没有人有任何建议？

解决方案

为了使用带有BDR的迁移，您需要手动创建迁移，仅使用安全操作，因为BDR目前无法复制迁移中的操作。 / p>

在最近我在第二象限（BDR开发的主要赞助商）的电子邮件对话中，我获得了有关这个主题的信息：

传递此信息没有时间表。这很难完成。

您仍然可以更改列的类型，它只需要多个步骤。在
一般情况下，您可以在BDR中执行DDL，就像您在库存PostgreSQL中使用
锁避免方法一样。所以在这种情况下，您可以：

• 添加没有DEFAULT的新列，并且没有任何NOT NULL并提交。如果需要，还会创建一个触发器，以便在插入值时自动填充新的
  列。或者更改新列以设置
  DEFAULT，如果这更合适。


• 更新表以将值复制到具有新类型的新列


• 更改表格使其不适用


• 删除旧列

我还发现这个来自BrainTree的文章将成为可以被视为安全操作的重要参考，以及如何重写迁移中的行为。

I am trying to run Django migrations on a Postgres database with BDR.

python manage.py makemigrations

works fine, but running

python manage.py migrate

results in the following error:

ALTER TABLE … ALTER COLUMN TYPE … may only affect UNLOGGED or TEMPORARY tables when BDR is active; auth_permission is a regular table

The offending module is django/django/contrib/auth/migrations/0002_alter_permission_name_max_length.py.

I am not finding anything on how to UNLOGGED tables using Django, especially, since auth_permissions is a Django table (not created by me). I am also not sure if UNLOGGED tables will replicate.

Does anyone have any advice?

解决方案

In order to use migrations with BDR, you would need to create your migrations by hand, using only "safe" operations, because BDR is not currently able to replicate operations such as the one in your migration.

In an email conversation I had recently with support at 2nd Quadrant (the primary sponsors of BDR development), I was given this information on the topic:

There is no timeline in delivering this. It's very hard to accomplish.

You can still alter a column's type, it just takes multiple steps. In general, you do DDL in BDR as if you were doing it with a lock-avoidance approach in stock PostgreSQL. So in this case you:

• ADD the new column without a DEFAULT and without any NOT NULL, and commit. If needed, also create a trigger to automatically fill the new column when values are inserted. Or ALTER the new column to set a DEFAULT, if that's more appropriate.
• UPDATE the table to copy values to the new column with new type
• ALTER the table to make it NOT NULL if appropriate
• DROP the old column

I also found this article from BrainTree to be a great reference for what could be considered "safe" operations, and how you would have to rewrite the behavior in your migrations.

这篇关于Django 1.8迁移与Postgres BDR 9.4.1的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！