问题标签 [django-migrations]

我在 Heroku 上运行 Django 1.7。我已经对 models.py 文件进行了更改（在表中添加了一列），但 Django 似乎无法检测到这一点。当我跑

它响应在应用程序中未检测到更改。

我试过删除 appname/migrations 文件夹，但这没有帮助。

有没有办法让 Django 重新扫描数据库并检查差异？这对南来说很容易。

我正在为 Django 1.7 更新我的应用程序，并尝试python manage.py makemigrations使用以下错误的结果：

TypeError: unbound method deconstruct() must be called with RegexValidator instance as first argument (got nothing instead)

我的模型：

实际上它更复杂，但我认为这会导致错误。我正在使用 Python 2.7。

我已经阅读了关于迁移的 Django 文档，包括添加 deconstruct() 方法和关于RegexValidator，但我不明白如何摆脱错误。

我有一个更新一些权限的数据迁移。我知道迁移中的权限存在一些已知问题，并且我能够通过在迁移中创建权限来避免一些麻烦（而不是使用模型中的元组快捷方式）。

迁移：

经过一些试验和错误后，我能够使用它来完成这项工作，manage.py migrate但我在测试中遇到了错误manage.py test。

调试了一下发现，ContentType在测试中运行时，此时迁移中没有（不知道为什么）。按照这篇文章中的建议，我尝试在它自己的迁移中手动更新内容类型。添加 ：

在获取Invitation模型的内容类型之前。收到以下错误

必须有某种方法以可测试的方式在数据迁移中创建/更新权限。

谢谢。

编辑

最后通过添加使其工作

奇怪的是，这还不够

我很想知道为什么所有这些都是必要的

当我将具有 ForeignKey 的新模型迁移到自定义用户模型时，我收到错误消息：

它在 Django 1.7 中。

我的自定义用户是apps.models.EmailUser.

以下是相关代码：

最后，这是迁移文件：

完整的错误回溯

额外信息

我注意到有一个测试来查看它是否在 django.db.migrations.state.render() 中使用自定义用户模型，但只有在使用 ignore_swappable=True 调用渲染时才会认真对待这个测试，而事实并非如此就我而言。

有什么想法吗？

我使用 Django 1.7 迁移，特别是想用初始数据填充新创建的数据库。因此，我为此使用了数据迁移。它看起来像这样：

同时，我想UserDetails为每个新用户创建一个模型实例：

但是：此信号仅在迁移之外有效。原因是这与没有发送信号有apps.get_model("auth", "User")很大不同。django.contrib.auth.models.User如果我尝试像这样手动执行此操作，则会失败：

这失败了，因为那时，信号处理程序尝试使用 O2O创建一个指向历史的新 指针：UserDetails User

真可惜。

好的，我可以直接调用信号处理程序。但是我必须在关键字参数中传递历史UserDetails类（以及它需要的其他历史类）。此外，具有 的应用程序UserDetails不是具有此数据迁移的应用程序，因此这将是一个丑陋的依赖关系，很容易破坏，例如，如果UserDetails应用程序从INSTALLED_APPS.

那么，这仅仅是我必须用丑陋的代码和 FixMe 注释来解决的当前限制吗？或者有没有办法从数据迁移中发送信号？

所以我最近从 South 迁移到本地 Django 迁移。迁移我的迁移一切顺利，但是最近的一些更改没有奏效。

我有一个模型：

我改成这样：

没有接受此更改./manage.py makemigrations，但该字段上有一个表示NOT NULL我无法创建留空的实例 - 我得到：MyModelf1

我能做些什么？我正在使用 MySQL 后端。

我已经在问题中检查了这个问题，但找不到任何关于 Django 在迁移中构建的简单解释，或者 - 它们足够可靠吗？

我使用 Django 1.7 开始了新项目，并在迁移中遇到了很多问题。在南方很正常的简单事情在那个版本中引起了我的例外。例如，将 charfield 更改为外键会引发无法将字段类型转换为 int 的错误，这是正常的，这就是我进行迁移的原因。正如我知道在我以前的项目中我必须与 South 做的事情一样，我强烈怀疑 django 迁移将处理此类操作？例如自定义字段自省，将外键转换为多线程，抽象类更改为字段，等等......所以我的问题是：

Django 1.7 内置迁移对于大型复杂的标准化数据库结构是否足够可靠？

PS至少和南一样强大（如果问题出在我使用它们我会处理它，但我不想陷入我的项目准备好，数据库有很多记录并且我必须改变的情况需要删除表和其他危险操作的东西）。

I am creating some dynamic Django models in my application and everything seems to be working as expected except for the migration system.

If I create a dynamic Django model and set managed = False, Django's makemigrations command still generates a migration for that new model. The migration looks something like this:

If I don't create the migration, when I run python manage.py migrate, I see the following message (in big scary red letters):

Is there a way to tell the migrations system in Django 1.7 to ignore unmanaged models all together? or perhaps a migrations = False setting in the Meta class of the models?

UPDATE: for clarification, I am using a method to create my dynamic models similar to the ones describe in the following places:

• http://dynamic-models.readthedocs.org/en/latest/topics/model.html#topics-model
• https://code.djangoproject.com/wiki/DynamicModels

This method is great for generating my dynamic models based on information stored in my Configuration models (https://code.djangoproject.com/wiki/DynamicModels#Adatabase-drivenapproach). I did have to register a signal to clear the django model cache to catch changes to the models when a Configuration instance is changed, but everything seems to be working great, except for the fact that migrations are generated for these models. If I delete one of the configurations and the model is deleted from Django's cache, the migration would need to be updated again, removing the model that it shouldn't care about.

These dynamic models are not used in the application specifically. No where in the code do I refer to a books model (from the example above). They are generated at runtime and used to read information from the legacy tables they provide access to.

I have been trying to synchronize changes to a model in a Django app using migrations in 1.7 (postgres 9.1 - let me know if you need more details of my environment), but manage.py migrate doesn't seem to do anything, and sqlmigrate doesn't emit any SQL.

I thought Django 1.7 - "No migrations to apply" when run migrate after makemigrations might be applicable to my situation, and I did find some history in the django_migrations table in my database. I deleted the records for the app I am trying to migrate.

Recently I gave up on getting the alter table statements to generate/run and dropped the original version of the table. And while manage.py migrate states it is applying the migration, nothing happens to the database.

Here are the steps I've been trying:

Delete the history.

Create an initial migration.

manage.py migrate returns the following:

Then I swap in the new models and generate a new migration.

The result of makemigrations is in myapp/migrations/0002_notificationlog.py:

Run this migration:

manage.py migrate acts like everything is OK:

I can see the log entries appear in django_migrations, but the table is not created.

I'm lost. Any idea what to try next?

Update

When running migrate -v 3 as requested, I see

followed by a similar line for each installed app.

Then

repeated a total of 13 times, the number of unmanaged apps.

Then

followed by

with a similar line for each installed app.

For migration 0002, the output is the same, except for

Note also that sqlmigrate doesn't output anything either:

Produces nothing at all.

Update 2

I copied myapp into a new project and was able to run migrations on it, but migrations stopped working when I imported my main project settings. Are there settings I should be aware of that could affect migration execution, particularly if I've been using South with previous versions of Django?

有post_syncdb信号可以在 syncdb 之后执行可以执行的操作。在加载固定装置后，即在命令之后，是否有类似的钩子来执行一些操作python manage.py loaddata？

我有一个脚本，可以创建一个新数据库、运行 migrate (syncdb) 并从 JSON 设备加载数据。发布所有这些，我想为已创建的用户创建组和权限。我在哪里插入该代码？

PS 使用post_migrate而不是post_syncdb1.7+