2

1.7 の移行 (postgres 9.1 - 私の環境の詳細が必要な場合はお知らせください) を使用して Django アプリのモデルへの変更を同期しようとしていますが、manage.py migrate は何もしていないようで、sqlmigrate SQL を出力しません。

Django 1.7 - makemigrationsの後に migrate を実行すると「No migrations to apply」が私の状況に適用される可能性があると考えましたが、データベースの django_migrations テーブルにいくつかの履歴が見つかりました。移行しようとしているアプリのレコードを削除しました。

最近、alter table ステートメントを生成/実行することをあきらめ、元のバージョンのテーブルを削除しました。そして、manage.py migrate は移行を適用していると述べていますが、データベースには何も起こりません。

私が試してきた手順は次のとおりです。

履歴を削除します。

rm -r myapp/migrations
../manage.py dbshell
myapp_db=> delete from django_migrations where app='myapp'

初期移行を作成します。

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

manage.py migrate は次を返します。

....
Running migrations:
  Applying myapp.0001_initial... FAKED

次に、新しいモデルを交換して、新しい移行を生成します。

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

makemigrations の結果は 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,),
        ),
    ]

この移行を実行します。

../manage.py migrate

manage.py migrate はすべて問題ないように動作します。

....
Running migrations:
  Applying myapp.0002_notificationlog... OK

django_migrations にログ エントリが表示されているのがわかりますが、テーブルは作成されていません。

道に迷いました。次に何を試してみますか？

アップデート

要求に応じて migrate -v 3 を実行すると、

Running pre-migrate handlers for application auth

インストールされているアプリごとに同様の行が続きます。

それで

Loading 'initial_data' fixtures...
Checking '/var/www/environment/default/myproj/myproj' for fixtures...
No fixture 'initial_data' in '/var/www/environment/default/myproj/myproj'.

合計 13 回繰り返し、管理されていないアプリの数です。

それで

Running migrations:
  Applying myapp.0001_initial... FAKED

に続く

Running post-migrate handlers for application auth

インストールされているアプリごとに同様の行があります。

移行 0002 の場合、出力は同じですが、次の点が異なります。

Running migrations:
  Applying myapp.0002_notificationlog... OK

また、sqlmigrate も何も出力しないことに注意してください。

../manage.py sqlmigrate myapp 0002 -v 3

まったく何も生み出しません。

更新 2

myapp を新しいプロジェクトにコピーして移行を実行できましたが、メイン プロジェクトの設定をインポートすると移行が機能しなくなりました。特に Django の以前のバージョンで South を使用している場合、移行の実行に影響を与える可能性があることに注意する必要がある設定はありますか?

4

1 に答える 1

5

この問題は、一般的なプロジェクト設定で解消され、古い複雑なプロジェクト設定で再発しました。メソッドが欠落しているデータベース Router クラスまで問題を追跡しましたallow_migrate。

DATABASE_ROUTERS = [ 'myproj.routers.DatabaseAppsRouter', ]

このルーターを使用して、プロジェクト内の別のアプリ (読み取り専用/MySQL) のクエリを処理します。

残念ながら、Django のドキュメントには次のように明確に記載されているため、自分以外の誰かを責めることはできません。

移行は、[allow_migrate] が False を返すモデルに対して何も操作を実行しないことに注意してください。（リンク）

このルーターは少し前に作成したものでallow_migrate、Django 1.7 にアップグレードしたときにルーター クラスにメソッドを追加しませんでした。メソッドを追加し、True必要なときに返されることを確認すると、移行が実行され、問題が解決されます。

于 2014-10-30T00:06:39.527 に答える