blocks|key|212761|text|每一次迁移都在一个事务内部。在PostgreSQL中，您不能在一个事务中更新表，然后更改表架构。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|212762|您需要将数据迁移和模式迁移分开。首先使用以下代码创建数据迁移：|212763|+for+sender+in+orm['fooapp.EmailSender'].objects.filter(footer=None):
++++sender.footer=''
++++sender.save()|code-block|syntax|javascript|212764|然后创建模式迁移：|212765|manage.py+schemamigration+fooapp+--auto|212766|现在您有了两个事务，两个步骤的迁移应该可以工作了。|212767|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

Every migration is inside a transaction. In PostgreSQL you must not update the table and then alter the table schema in one transaction.

You need to split the data migration and the schema migration. First create the data migration with this code:

<pre><code> for sender in orm['fooapp.EmailSender'].objects.filter(footer=None):
 sender.footer=''
 sender.save()
</code></pre>

Then create the schema migration:

<pre><code>manage.py schemamigration fooapp --auto
</code></pre>

Now you have two transactions and the migration in two steps should work.

blocks|key|212798|text|另一个原因可能是您试图将列设置为NOT+NULL，而它实际上已经具有NULL值。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|212799|entityMap^0|G|8|Y|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

Another reason for this maybe because you try to set a column to <code>NOT NULL</code> when it actually already has <code>NULL</code> values.

blocks|key|3064937|text|在操作中，我设置了约束：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3064938|operations+=+[
++++migrations.RunSQL('SET+CONSTRAINTS+ALL+IMMEDIATE;'),
++++migrations.RunPython(migration_func),
++++migrations.RunSQL('SET+CONSTRAINTS+ALL+DEFERRED;'),
]|code-block|syntax|javascript|3064939|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

At the operations I put SET CONSTRAINTS:

<pre><code>operations = [
 migrations.RunSQL('SET CONSTRAINTS ALL IMMEDIATE;'),
 migrations.RunPython(migration_func),
 migrations.RunSQL('SET CONSTRAINTS ALL DEFERRED;'),
]
</code></pre>

blocks|key|3065017|text|如果要添加不可为空的字段，则需要进行两次迁移：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3065018|填充it|3065019|AlterField的|unordered-list-item|offset|length|style|CODE|3065020|AddField和RunPython将该字段更改为不可为空的|ordered-list-item|3065021|3065022|3065023|3065024|解释|3065025|在PostgreSQL和SQLite上，如果在同一迁移中有足够复杂的RunPython命令和模式更改，则可能会出现此问题。例如，如果要添加一个不可为空的字段，则典型的迁移步骤如下：|3065026|3065027|AddField将字段作为nullable|3065028|RunRython添加以填充it|3065029|AlterField将字段更改为non-nullable|3065030|3065031|在SQLite和Postgres上，这可能会导致问题，因为所有的事情都是在一个事务中完成的。|3065032|Django+docs对此有一个特定警告：|3065033|3065034|在支持DDL事务的数据库(SQLite和PostgreSQL)上，除了为每次迁移创建的事务外，RunPython操作不会自动添加任何事务。因此，例如在PostgreSQL上，您应该避免在同一迁移中组合模式更改和RunPython操作，否则可能会遇到诸如OperationalError:+cannot+ALTER+TABLE+"mytable“这样的错误，因为它有挂起的触发器事件。|blockquote|3065035|3065036|3065037|如果是这种情况，解决方案是将您的迁移分成多个迁移。通常，拆分的方法是让第一个迁移包含通过run_python命令向上执行的步骤，第二个迁移包含后面的所有步骤。因此，在上述情况下，模式将是一次迁移中的AddField和RunPython，以及第二次迁移中的AlterField。|3065038|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.djangoproject.com/en/dev/ref/migration-operations/#runpython^0|0|0|0|A|0|0|8|9|9|0|0|0|0|0|Y|9|0|0|0|8|0|0|9|0|0|A|0|0|0|0|B|0|0|0|0|0|0|2R|8|30|9|3J|A|0^^$0|@$1|2|3|4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|1O|8|@$G|1P|H|1Q|I|J]]|9|@]|A|$]]|$1|K|3|L|5|M|7|1R|8|@$G|1S|H|1T|I|J]|$G|1U|H|1V|I|J]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|20|8|@$G|21|H|22|I|J]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|23|8|@]|9|@]|A|$]]|$1|V|3|W|5|M|7|24|8|@$G|25|H|26|I|J]]|9|@]|A|$]]|$1|X|3|Y|5|M|7|27|8|@$G|28|H|29|I|J]]|9|@]|A|$]]|$1|Z|3|10|5|M|7|2A|8|@$G|2B|H|2C|I|J]]|9|@]|A|$]]|$1|11|3|-4|5|6|7|2D|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|2E|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|2F|8|@]|9|@$G|2G|H|2H|1|2I]]|A|$]]|$1|16|3|-4|5|6|7|2J|8|@]|9|@]|A|$]]|$1|17|3|18|5|19|7|2K|8|@]|9|@]|A|$]]|$1|1A|3|-4|5|6|7|2L|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|2M|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|2N|8|@$G|2O|H|2P|I|J]|$G|2Q|H|2R|I|J]|$G|2S|H|2T|I|J]]|9|@]|A|$]]|$1|1E|3|-4|5|6|7|2U|8|@]|9|@]|A|$]]]|1F|$1G|$5|1H|1I|1J|A|$1K|1L]]]]

If you are adding a non-nullable field, you need to do it in two migrations:
<ol>
<li><code>AddField</code> and <code>RunPython</code> to populate it</li>
<li><code>AlterField</code> to change the field to be non-nullable</li>
</ol>
<hr />
<h1>Explaniation</h1>
On PostgreSQL and SQLite, this problem can occur if you have a sufficiently complex <code>RunPython</code> command combined with schema alterations in the same migration. For example, if you are adding a non-nullable field, the typical migration steps for this is:
<ol>
<li><code>AddField</code> to add the field as nullable</li>
<li><code>RunRython</code> to populate it</li>
<li><code>AlterField</code> to change the field to be non-nullable</li>
</ol>
On SQLite and Postgres, this can cause problems because the whole thing is being done in one transaction. 
The <a href="https://docs.djangoproject.com/en/dev/ref/migration-operations/#runpython" rel="noreferrer">Django docs</a> have a specific warning about this:
<blockquote>
On databases that do support DDL transactions (SQLite and PostgreSQL), RunPython operations do not have any transactions automatically added besides the transactions created for each migration. Thus, on PostgreSQL, for example, you should avoid combining schema changes and RunPython operations in the same migration or you may hit errors like OperationalError: cannot ALTER TABLE &quot;mytable&quot; because it has pending trigger events.
</blockquote>
If this is the case, the solution is to separate your migration into multiple migrations. In general, the way to split is to have a first migration containing the steps up through the run_python command and the second migration containing all the ones after it. Thus, in the case described above, the pattern would be the <code>AddField</code> and <code>RunPython</code> in one migration, and the <code>AlterField</code> in a second.

blocks|key|211287|text|刚刚遇到了这个问题。您还可以在模式迁移中使用db.start_transaction()和db.commit_transaction()将数据更改与模式更改分开。可能不是很干净，无法进行单独的数据迁移，但在我的情况下，我需要模式、数据，然后是另一个模式迁移，所以我决定一次完成所有的迁移。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|211288|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Have just hit this problem. You can also use db.start_transaction() and db.commit_transaction() in the schema migration to separate data changes from schema changes. Probably not so clean as to have a separate data migration but in my case I would need schema, data, and then another schema migration so I decided to do it all at once.

blocks|key|212828|text|您正在更改列架构。该脚注列不能再包含空值。对于该列，数据库中很可能已经存储了空值。Django将使用migrate命令将数据库中的那些空白行从空白更新为现在的默认值。Django尝试更新footer列为空值的行，同时似乎(我不确定)更改模式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|212829|问题是，您不能同时更改正在尝试更新值的同一列模式。|212830|一种解决方案是删除迁移文件，更新模式。然后，运行脚本将所有这些值更新为默认值。然后重新运行迁移以更新架构。这样，更新就已经完成了。Django迁移只是改变了模式。|212831|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

You are altering the column schema. That footer column can no longer contain a blank value. There are most likely blank values already stored in the DB for that column. Django is going to update those blank rows in your DB from blank to the now default value with the migrate command. Django tries to update the rows where footer column has a blank value and change the schema at the same time it seems (I'm not sure).

The problem is you can't alter the same column schema you are trying to update the values for at the same time. 

One solution would be to delete the migrations file updating the schema. Then, run a script to update all those values to your default value. Then re-run the migration to update the schema. This way, the update is already done. Django migration is only altering the schema.

blocks|key|3065068|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3065069|第1步)解决方案是从迁移文件夹中删除最新的迁移，并删除模型中最新添加的字段。步骤2)然后再次进行迁移步骤3)最后再次添加在第一步中删除的字段步骤4)然后再次进行迁移和迁移|blockquote|3065070|3065071|3065072|问题已解决|3065073|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|J|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|K|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|L|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|M|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|N|7|@]|8|@]|9|$]]|$1|H|3|-4|4|5|6|O|7|@]|8|@]|9|$]]]|I|$]]

<blockquote>
step 1)the solution is to remove the latest migration from the migration folder and remove the latest added fields in models.
</blockquote>
<blockquote>
step 2)then again makemigration and migrate
</blockquote>
<blockquote>
step 3)At the last add the field again that has been removed in the first step
</blockquote>
<blockquote>
step 4)then again makemigration and migrate
</blockquote>
<h2>Problem solved</h2>

blocks|key|210953|text|在我的情况下，我有|type|unstyled|depth|inlineStyleRanges|entityRanges|data|210954|210955|AddField|ordered-list-item|210956|RunPython|210957|RemoveField|210958|210959|然后，我将最后一个RemoveFied移到新的迁移文件中，这样就解决了这个问题|210960|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|S|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

In my case I've got
<ol>
<li>AddField</li>
<li>RunPython</li>
<li>RemoveField</li>
</ol>
Then I just moved the last RemoveFied to the new migration file, that fixed the problem

I want to remove null=True from a TextField:

<pre><code>- footer=models.TextField(null=True, blank=True)
+ footer=models.TextField(blank=True, default='')
</code></pre>

I created a schema migration:

<pre><code>manage.py schemamigration fooapp --auto
</code></pre>

Since some footer columns contain <code>NULL</code> I get this <code>error</code> if I run the migration:

<blockquote>
 django.db.utils.IntegrityError: column "footer" contains null values
</blockquote>

I added this to the schema migration:

<pre><code> for sender in orm['fooapp.EmailSender'].objects.filter(footer=None):
 sender.footer=''
 sender.save()
</code></pre>

Now I get:

<pre><code>django.db.utils.DatabaseError: cannot ALTER TABLE "fooapp_emailsender" because it has pending trigger events
</code></pre>

What is wrong?

Django-DB-Migrations: cannot ALTER TABLE because it has pending trigger events

数据迁移

PostgreSQL

数据库

Django

SQLite

我想从TextField中删除null=True：-    footer=models.TextField(null=True, blank=True)+    footer=models.TextField(blank=True, default='')我创建了一个模式迁移：manage.py schemamigration fooapp --auto因为一些脚注列包含NULL，所以如果我运行迁

问Django-DB-Migrations:无法更改表，因为它有挂起的触发器事件
EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Django-DB-Migrations:无法更改表，因为它有挂起的触发器事件EN

回答 8

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Django-DB-Migrations:无法更改表，因为它有挂起的触发器事件
EN