Django的south(迁移工具)适用于innodb吗?
$ py manage.py migrate turkey
Running migrations for turkey:
- Migrating forwards to 0001_initial.
> turkey:0001_initial
! Error found during real run of migration! Aborting.
! Since you have a database that does not support running
! schema-altering statements in transactions, we have had
! to leave it in an interim state between migrations.
! You *might* be able to recover with: = DROP TABLE `turkey_demorecs` CASCADE; []
! The South developers regret this has happened, and would
! like to gently persuade you to consider a slightly
! easier-to-deal-with DBMS.
! NOTE: The error which caused the migration to fail is further up.
出于某种原因,当我尝试时我得到了这个。 但我的其他设置是在 MyISAM 中。
为什么它在 Innodb 中不起作用?
$ py manage.py migrate turkey
Running migrations for turkey:
- Migrating forwards to 0001_initial.
> turkey:0001_initial
! Error found during real run of migration! Aborting.
! Since you have a database that does not support running
! schema-altering statements in transactions, we have had
! to leave it in an interim state between migrations.
! You *might* be able to recover with: = DROP TABLE `turkey_demorecs` CASCADE; []
! The South developers regret this has happened, and would
! like to gently persuade you to consider a slightly
! easier-to-deal-with DBMS.
! NOTE: The error which caused the migration to fail is further up.
For some reason I get this when I try it.
But my other setups are in MyISAM.
Why doesn't it work in Innodb?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
InnoDB 对外键有限制,确保您在进行迁移时不会破坏数据库模型。 (参见http://dev.mysql.com /doc/refman/5.5/en/innodb-foreign-key-constraints.html)
MyISAM 没有对约束的本机支持(尽管如果您选择这样做 http://dev.mysql.com/tech-resources/articles/mysql- enforcing-foreign-keys.html)
因为 MyISAM 不检查您的 FK 关系,所以您不会收到错误。然而,InnoDB 正在进行检查,看来您的迁移有问题。
InnoDB has constraints on Foreign Keys which ensure you are not breaking the database model when doing a migration. (see http://dev.mysql.com/doc/refman/5.5/en/innodb-foreign-key-constraints.html)
MyISAM does not have native support for constraints (although it seems you can implement this if you choose to do do http://dev.mysql.com/tech-resources/articles/mysql-enforcing-foreign-keys.html)
Because MyISAM is not checking your FK relationships, you do not get the error. InnoDB however is doing a check and it seems that you have a problem with your migration.
另请参阅 https://code.djangoproject.com/wiki/AlterModelOnSyncDB
我也有过同样的情况当我使用默认表存储引擎是 MyISAM 的 mysql 设置时发生了错误,并且我想使用 InnoDB(使用上面链接中找到的配方,我们使用
post_syncdb
信号来触发转换代码)。然而,当使用 South 创建新表时,它们首先使用 MyISAM 引擎创建,然后再进行转换。我错误地认为 InnoDB 表没有做它们应该做的事情,而实际上它们是 MyISAM;因为表是由信号转换的,所以任何迁移错误都将无法取消应用:-/如果您需要使用或创建默认为 MyISAM 的 InnoDB 表,则可以通过以下方式解决:
或者如果您不介意性能下降:
See also https://code.djangoproject.com/wiki/AlterModelOnSyncDB
I have had the same kind of error happen to me when working with a mysql setup whose default table storage engine is MyISAM and I wanted to use InnoDB (using the recipe found in above link, we used the
post_syncdb
signal to trigger the conversion code). However, when using South to create new tables they were first created using MyISAM engine then later converted. I was mistakenly believing InnoDB tables weren't doing what they were supposed to, when those were actually MyISAM; because the table were converted by the signal, any migration error would fail to unapply :-/If you need to use or create InnoDB tables where the default is MyISAM, this be solved with:
or if you do not mind the performance hit:
是的,South确实支持InnoDB。您可以删除“migrations”文件夹的内容,然后重新运行 schemamigration、迁移并在此处发布 0001_initial 文件的结果和内容吗? PS:首先确保您的迁移文件夹已备份或位于源代码管理中。
Yes, South does support InnoDB. Can you delete the contents of your "migrations" folder, and re-run schemamigration, migrate, and post the results and contents of the 0001_initial file here? PS: Make sure you have your migrations folder backed up or in source control first.
您可以尝试添加到您的第一次迁移:
这将禁用外键检查约束。
您不必将其设置回 1,因为它是会话变量。
顺便说一句,如果您在迁移方法的开始处设置为 0,并在迁移方法结束时设置为 1,则该方法不起作用,因为 South 会使用它们生成 SQL,但会在它们返回时执行它。
You could try adding to your first migration:
This will disable the foreign key check constraints.
You don't have to set it back to 1 since it's a session variable.
By the way, it doesn't work if you set to 0 at the beggining and back to 1 at the end of your migration method, because south generates SQL with them, but executes it when they return.