Django中的Django迁移1.7检测模型更改，但不适用于迁移 [英] Django-migrations in Django 1.7 detects model changes but does not apply them on migrate

问题描述

我一直在尝试使用1.7中的迁移（postgres 9.1 - 让我知道，如果您需要更多的环境细节）在Django应用程序中同步更改模型，但是manage.py migrate似乎没有做任何事情，而sqlmigrate不会发出任何SQL。

我以为 Django 1.7 - 无迁移应用运行迁移之后运行可能适用于我的情况，而且我在数据库的django_migrations表中找到了一些历史记录。我删除了我正在迁移的应用程序的记录。

最近我放弃了获取alter table语句来生成/运行并删除了表的原始版本。而在manage.py迁移状态时，它正在应用迁移，数据库中没有任何反应。

以下是我一直在尝试的步骤：

删除历史记录。

  rm -r myapp / migrations 
 ../ manage.py dbshel​​l 
 myapp_db =>从django_migrations删除，其中app ='myapp'
  

创建初始迁移。

  cp myapp / models.py.orig myapp / models.py 
 ../manage.py makemigrations myapp 
 ../manage .py migrate 
  

manage.py migrate返回以下内容：

  .... 
运行迁移：
应用myapp.0001_initial ... FAKED 
  

然后我交换新的模型并生成新的迁移。

  cp myapp / models.py.new myapp / models.py 
 ../manage.py makemigrations myapp 
  

makemigrations的结果是在myapp / migrations / 0002_notificationlog.py中：

 ＃ -  *  - 编码：$ _ 
从__future__导入unicode_literals 
 
从django.db导入模型，迁移
 
 
类迁移（迁移。迁移） ：
 
依赖关系= [
（'myapp'，'0 001_initial'），
] 
 
 operations = [
 migrations.CreateModel（
 name ='NotificationLog'，
 fields = [
 'id'，models.AutoField（verbose_name ='ID'，serialize = False，auto_created = True，primary_key = True）），
（'tstamp'，models.DateTimeField（help_text = b'Log time'，auto_now_add = true）），
（'recipient'，models.CharField（max_length = 100）），
（'subject'，models.TextField（）），
]，
 options = {
}，
 bases =（models.Model，），
），
] 
  

运行此迁移：

  ../ manage.py migrate 
  

manage.py迁移行为就像一切都OK：

  .... 
运行迁移：
应用myapp.0002_notificationlog ... OK 
  

我可以看到日志条目显示在django_migrations中，但表不会创建。

我迷路了。任何想法下一步呢？

更新

运行migrate -v 3请求，我看到

 为应用程序auth运行预迁移处理程序
  / pre> 
 
 
之后是每个已安装应用程序的类似行。
 
 
 
然后
 加载'initial_data'灯具... 
检查'/ var / www / environment / default / myproj / myproj'为灯具... 
/ var / www / environment / default / myproj / myproj中没有fixture'initial_data'。 
  
重复共13次，非托管应用的数量。
 
 
 
然后
 运行迁移：
应用myapp.0001_initial ... FAKED 
  
后跟
 为应用程序auth运行迁移后处理程序auth 
  
与每个已安装应用程序的行类似。 p> 
 
 
对于迁移0002，输出是相同的，除了
 正在运行迁移：
应用myapp.0002_notificationlog ... OK 
  
还要注意，sqlmigrate不输出任何东西：
  ../ manage.py sqlmigrate myapp 0002 -v 3 
  
根本没生产。
 
 
 
 更新2  p> 
 
 
我将myapp复制到一个新项目中，并能够在其上运行迁移，但是当我导入我的主项目设置时，迁移停止工作英格斯。有没有我应该知道的设置可能会影响迁移执行，特别是如果我一直在使用以前版本的Django的南方？ 
解决方案
通用项目设置中的问题消失，并重新出现我的旧的复杂项目设置。我将问题跟踪到缺少 allow_migrate 方法的数据库路由器类。 
  DATABASE_ROUTERS = ['myproj.routers.DatabaseAppsRouter'，] 
  
我使用此路由器来处理项目中的单独应用程序的查询（只读/ MySQL）。
 
 
 
可悲的是，除了自己以外，我不能怪任何人，因为 Django文档清楚地说明：
 
 
请注意，迁移只会默认不对[allow_migrate]返回False的模型执行任何操作。 （link） 
 
 
我之前已经创建了这个路由器，当我升级到我的路由器类时没有添加 allow_migrate 方法到我的路由器类到Django 1.7。当我添加该方法并确保在需要时返回 True ，迁移运行，问题解决。
 
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.
rm -r myapp/migrations
../manage.py dbshell
myapp_db=> delete from django_migrations where app='myapp'
Create an initial migration.
cp myapp/models.py.orig myapp/models.py
../manage.py makemigrations myapp
../manage.py migrate
manage.py migrate returns the following:
....
Running migrations:
  Applying myapp.0001_initial... FAKED
Then I swap in the new models and generate a new migration.
cp myapp/models.py.new myapp/models.py
../manage.py makemigrations myapp
The result of makemigrations is in myapp/migrations/0002_notificationlog.py:
# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models, migrations


class Migration(migrations.Migration):

    dependencies = [
        ('myapp', '0001_initial'),
    ]

    operations = [
        migrations.CreateModel(
            name='NotificationLog',
            fields=[
                ('id', models.AutoField(verbose_name='ID', serialize=False, auto_created=True, primary_key=True)),
                ('tstamp', models.DateTimeField(help_text=b'Log time', auto_now_add=True)),
                ('recipient', models.CharField(max_length=100)),
                ('subject', models.TextField()),
            ],
            options={
            },
            bases=(models.Model,),
        ),
    ]
Run this migration:
../manage.py migrate
manage.py migrate acts like everything is OK:
....
Running migrations:
  Applying myapp.0002_notificationlog... 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 
Running pre-migrate handlers for application auth
followed by a similar line for each installed app.

Then
Loading 'initial_data' fixtures...
Checking '/var/www/environment/default/myproj/myproj' for fixtures...
No fixture 'initial_data' in '/var/www/environment/default/myproj/myproj'.
repeated a total of 13 times, the number of unmanaged apps.

Then
Running migrations:
  Applying myapp.0001_initial... FAKED
followed by
Running post-migrate handlers for application auth
with a similar line for each installed app.

For migration 0002, the output is the same, except for
Running migrations:
  Applying myapp.0002_notificationlog... OK
Note also that sqlmigrate doesn't output anything either:
../manage.py sqlmigrate myapp 0002 -v 3
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? 
解决方案
The problem disappeared with generic project settings and reappeared with my old, complex project settings. I tracked the problem down to a database Router class that was missing an allow_migrate method. 
DATABASE_ROUTERS = [ 'myproj.routers.DatabaseAppsRouter', ]
I use this router to handle queries for a separate app in the project (readonly/MySQL).

Sadly I can't blame anyone but myself, since the Django documentation states clearly:

  
Note that migrations will just silently not perform any operations on a model for which [allow_migrate] returns False. (link)
I had created this router some time ago and didn't add the allow_migrate method to my router class when I upgraded to Django 1.7. When I added the method and made sure it returned True when needed, migrations run and the problem is solved.

                        
这篇关于Django中的Django迁移1.7检测模型更改，但不适用于迁移的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！