web-dev-qa-db-ja.com

Django 1.7 - makemigrationsが変更を検出しない

タイトルが言うように、私は移行がうまくいくようには思えません。

このアプリはもともと1.6未満だったので、最初は移行が行われないことを理解しています。実際にpython manage.py migrateを実行すると、次のようになります。

Operations to perform:
  Synchronize unmigrated apps: myapp
  Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
  Creating tables...
  Installing custom SQL...
  Installing indexes...
Running migrations:
  No migrations to apply.

myapp内のモデルに変更を加えても、期待どおりまだ未移行と表示されます。

しかしpython manage.py makemigrations myappを実行すると、次のようになります。

No changes detected in app 'myapp'

何をどうやって実行しても問題ありませんし、アプリケーションに変更があることを検出することも、アプリケーションに移行ファイルを追加することもありません。

アプリを強制的に移行させて、「これが私の仕事の基本」と言うような方法はありますか。それとも私は何かが足りないのですか？

私のデータベースはPostgreSQLのものです。

pythondjangodjango-1.7django-migrations
131
TyrantWave

わかりました、私は明白なステップを逃したように見えますが、他の誰かが同じことをする場合に備えてこれを投稿してください。

1.7にアップグレードすると、私のモデルは管理されなくなりました（managed = False） - 以前はTrueとしていましたが、元に戻されたようです。

その行を削除し（デフォルトはTrue）、それからmakemigrationsを実行するとすぐに移行モジュールが作成され、動作します。 makemigrationsは、管理されていないテーブルでは機能しません（これは後知恵で明らかです）。

27
TyrantWave

Django 1.6で作成した既存のアプリから切り替える場合は、ドキュメントに記載されている1つの事前手順（私が見つけたように）を実行する必要があります。

python manage.py makemigrationsyour_app_label

最初にやらなければならないことはpython manage.py makemigrationsで、これは失敗するので、ドキュメントはあなたがコマンドにappラベルを追加する必要があることを明白にしません。最初の移行は、バージョン1.7でアプリを作成したときに行われますが、1.6から来た場合は実行されませんでした。詳しくは、ドキュメントの 'アプリへの移行の追加' をご覧ください。

176
drojf

これは、以下の理由により発生する可能性があります。

  1. アプリをINSTALLED_APPSのリストsettings.pyに追加しませんでした（あなたはDjangoのバージョンに応じて、アプリ名またはappフォルダのapps.pyにあるAppConfigのサブクラスに点線のパスを追加します。を使用して）。ドキュメントを参照してください。 INSTALLED_APPS
  2. あなたはそれらのアプリの中にmigrationsフォルダを持っていません。 （解決策：そのフォルダを作成するだけです）。
  3. これらのアプリのmigrationsフォルダー内に__init__.pyファイルはありません。 （解決策：__ init __。pyという名前の空のファイルを作成するだけです）
  4. アプリフォルダの中に__init__.pyファイルがありません。 （解決策：__ init __。pyという名前の空のファイルを作成するだけです）
  5. アプリにmodels.pyファイルがありません
  6. models.pyのあなたのPythonクラス（モデルであるはず）は継承しませんDjango.db.models.Model
  7. models.pyでモデルの定義に意味上の誤りがあります。

注：よくある間違いは、.gitignoreファイルにmigrationsフォルダーを追加することです。リモートリポジトリからクローンを作成すると、migrationsフォルダや__init__.pyファイルがローカルリポジトリに表示されなくなります。これは問題を引き起こします。

.gitignoreファイルに次の行を追加して、移行ファイルを無視することをお勧めします。

*/migrations/*
!*/migrations/__init__.py
31
Mohammed Shareef C

私の解決策はここではカバーされていないので、私はそれを投稿しています。私はsyncdbをプロジェクトのために使っていました - ちょうどそれを立ち上げて実行するためです。それから私がDjangoのマイグレーションを使い始めようとしたとき、最初はそれらを偽造していましたが、それは 'OK'と言っていましたが、データベースには何も起こりませんでした。

私の解決策は、Django_migrationsテーブルのアプリ移行のデータベースレコードとして、私のアプリのすべての移行ファイルとを削除することでした。

それから私はちょうど最初の移行をしました：

./manage.py makemigrations my_app

に続く：

./manage.py migrate my_app

今私は問題なく移行を行うことができます。

18
Grant Eagon

@furinsに同意してください。すべてが順調に進んでいても問題が発生する場合は、Modelクラスに追加しようとしている属性と同じタイトルのプロパティメソッドがあるかどうかを確認します。

  1. 追加している属性と同じ名前のメソッドを削除してください。
  2. manage.py makemigrations my_app
  3. manage.pyマイグレーションmy_app
  4. メソッドを元に戻します。
15
Prashant Nair

これは愚かなミスですが、モデルクラスのフィールド宣言行の末尾に余分なカンマを追加しても、その行は無効になります。

あなたがdefをコピーペーストするときに起こります。それ自体が配列として定義されているマイグレーションから。

多分これは誰かに役立つだろう:-)

11
Iman Akbari

遅すぎるかもしれませんが、__init__.pyファイルを含むmigrationsフォルダーをアプリに入れようとしましたか？

10
rrrub

以下は私のために働いた：

  1. Settings.pyにアプリ名を追加してください
  2. 'python manage.py makemigrations'を使用してください。
  3. 'python manage.py migrate'を使用してください。

私のために働きました：Python 3.4、Django 1.10

7
Pranshu Gupta

答えはcdvv7788によるこのstackoverflow記事にあります Django 1.7での移行

それがあなたがそのアプリを移行しているのは初めての場合はあなたが使用する必要があります。

manage.py makemigrations myappnameこれを実行したら、次のことができます。

manage.py migrateデータベースにアプリがある場合は、モデルを変更し、makemigrationsの変更が更新されない場合は、まだ移行していない可能性があります。モデルを元の形式に戻し、最初のコマンドを（アプリ名を付けて）実行して移行します。それを行ったら、モデルへの変更を元に戻して、makemigrationsを実行し、再度移行してください。これでうまくいくはずです。

私は全く同じ悩みを抱えていて、上記をすることは完全にうまくいきました。

私は自分のDjangoアプリをcloud9に移行しましたが、何らかの理由で私は最初の移行に気付きませんでした。

7
MicahT

私のようにマイグレーションが好きでない人は、以下のステップを使うことができます。

  1. 同期したい変更を削除します。
  2. 最初の移行のためにpython manage.py makemigrations app_labelを実行してください。
  3. 変更を加える前にpython manage.py migrateを実行してテーブルを作成してください。
  4. 最初のステップで削除した変更を貼り付けます。
  5. 2.と3.の手順を実行します。

これらの手順のいずれかを混同した場合は、移行ファイルを読んでください。スキーマを修正するか不要なファイルを削除するように変更してください。ただし、次の移行ファイルの依存関係の部分を忘れずに変更してください。

これが将来誰かに役立つことを願っています。

6
Deniz Kaplan

多分これは誰かを助けるでしょう。入れ子になったアプリを使用していました。 project.appnameと私は実際にはINSTALLED_APPSにprojectとproject.appnameがありました。 INSTALLED_APPSからプロジェクトを削除すると、変更を検出できました。

6
jaywhy13

settings.pyリストのINSTALLED_APPSをチェックして、モデルを含むすべてのアプリがそこにリストされていることを確認します。

プロジェクトフォルダでmakemigrationsを実行すると、プロジェクトのsettings.pyに含まれるすべてのアプリに関連するすべてのテーブルが更新されるようになります。含めると、makemigrationsが自動的にアプリを含めます（これにより多くの作業が節約されるので、プロジェクト/サイト内のすべてのアプリに対してmakemigrations app_nameを実行する必要はありません）。

5
Sticky

念のため、makemigrationsで識別されない特定のフィールドがある場合は、同じ名前のプロパティがあるかどうかを2回チェックします。

例：

field = Django.db.models.CharField(max_length=10, default = '', blank=True, null=True)

# ... later

@property
def field(self):
    pass

プロパティはフィールド定義を「上書き」するため、変更はmakemigrationsによって識別されません。

4
furins

この方法だけが私を助けたので、この答えを追加しました。

migrationsとmakemigrationsを実行して、migrateフォルダーを削除しました。
まだ言っています：移行する必要はありません。

migrateフォルダに行き、最後に作成したファイルを開きました、
欲しい移行についてコメントします（検出され、そこで入力されました）
そしてmigrateをもう一度実行してください。

これは基本的に手動でマイグレーションファイルを編集することです。
ファイルの内容を理解している場合にのみこれを実行してください。

4
Jithin Pavithran

モデルがabstractではないことを確認してください。私は実際にその間違いをしました、そしてそれはしばらく時間がかかりました、それで私はそれを掲示すると思いました。

4
Mark

古い移行フォルダの名前を変更した後にschemamigration my_app --initialを使用しましたか？それを試してみてください。うまくいくかもしれません。そうでない場合 - データベースを再作成してsyncdb + migrateを実行してください。それは私のために働きました...

3
Alex Vidis

多分それは誰かを助けることができる、私は同じ問題を抱えていた。

シリアライザクラスとビューを使って2つのテーブルを作成しました。だから私が更新したいと思ったとき、私はこのエラーがありました。

私はこの手順に従った：

  1. 私は.\manage.py makemigrations appを作りました
  2. .\manage.py migrateを実行しました
  3. models.pyの両方のテーブルを消去しました
  4. シリアライザとビュークラスから自分のテーブルへの参照をすべて削除しました。
  5. ステップ1と2を実行しました。
  6. 私はちょうどmodels.pyで私の変更を取得しました
  7. ステップ5をもう一度実行しました。
  8. 私はすべての変更を元に戻しました。

あなたがPycharmを使っているのなら、地元の歴史はとても役に立ちます。

1
winter

私は2回makemigrationsを実行しなければならないことと同じような問題を抱えていました、そしてあらゆる種類の奇妙な行動。問題の根本は、私が自分のモデルにデフォルトの日付を設定するために関数を使っていたので、マイグレーションがmakemigrationsを実行するたびに変更を検出していたことです。この質問への答えは私を正しい軌道に乗せました： 日付フィールドを再作成するためのmakemigrationsを避けます

1
PhoebeB

私は最近Djangoを1.6から1.8にアップグレードし、それらのためのアプリと移行はほとんどありませんでした。 Django 1.6ではマイグレーションを作成するためにsouthとschemamigrationsを使用しました。これはDjango 1.8で削除されました。

アップグレード後に新しいモデルを追加したとき、makemigrationsコマンドで変更が検出されませんでした。それから私は@ drojf（最初の答え）によって提案された解決策を試してみました、それはうまくいきましたが、偽の初期移行（python manage.py --fake-initial）を適用するのに失敗しました。私のテーブル（古いテーブル）はすでに作成されているので、私はこれをしていました。

最後に、これは私にとってはうまくいき、models.pyから新しいモデル（またはモデルの変更）を削除し、それからすべてのアプリケーションのマイグレーションフォルダーを削除（または安全バックアップのために名前変更）し、すべてのアプリケーションに対してpython manage.py makemigrationsを実行し、そしてpython manage.py migrate --fake-initialを実行します。これは魅力のように働きました。すべてのアプリの初期移行が作成され、偽の初期移行が行われたら、新しいモデルを追加し、makemigrationsの通常のプロセスに従ってそのアプリに移行します。変更は今検出され、すべてうまくいきました。

私はここでそれを共有することを考えました、誰かが同じ問題に直面した場合（彼らのアプリのために南のschemamigrationsを持つ）、それはそれらを助けるかもしれません:)

1
RaghavHarpale

同じ問題がありました models.pyで定義したクラスがなんであれ、models.Modelクラスを継承する必要があることを確認してください。

class Product(models.Model):
    title = models.TextField()
    description = models.TextField()
    price = models.TextField()
1
Sonu Kumar
./manage makemigrations
./manage migrate

移行によってDBへの変更が追跡されるため、管理対象外から管理対象に変更する場合は、対象となるモデルに関連するデータベーステーブルが最新であることを確認する必要があります。

それでもdevモードの場合は、IDEと私のモデルに関連するDjango_migrationsテーブルの移行ファイルを個人的に削除して、上記のコマンドを再実行することにしました。

注意：データベースのIDE＆_003に_001で終わる移行がある場合。 Djangoは更新するものが何であれ_004で終わる移行があるかどうかだけを見ます。

2（コードとデータベースの移行）はリンクされており、連携して機能します。

ハッピーコーディング.

1
A H Bensiali

多分これは誰かを助けるでしょう。

私は私のmodels.pyを削除し、makemigrationsステートメントを作成するためにDeleteModelを期待しました。

*.pycファイルを削除することを忘れないでください。

1
Sebastian Wagner

上記の他に利用可能なものがどれも私のために働かなかったのでこの答えを加えた。

私の場合はさらに奇妙なことが起こっていました（Django 1.7バージョン）、私のmodels.py私のファイルの最後に "extra"の行がありました（それは空白行でした）そしてpython manage.py makemigrationsを実行した時 "変更は検出されませんでした"

これを修正するために、私はこの "空白行"を削除しました。これは私のmodels.pyファイルと私は再びコマンドを実行しました、すべてが修正され、models.pyに加えられたすべての変更が検出されました！

0
Huskie

以下のコマンドを使用して、初期移行を偽造する必要がある場合があります

python manage.py migrate --fake-initial
0
dtar