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


140

タイトルのとおり、移行がうまくいかないようです。

アプリはもともと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のデータベースです。


提供された解決策は私にとってうまくいかなかったので、誰かが同じ問題に直面した場合の解決策はここにあります!1.すべてのアプリの下の移行ファイルを削除します。2.データベースを削除して再度作成します。3. makemigrationsを実行し、コマンドを移行しますPS最初に手順1と3を試してください。それでもエラーが発生する場合は、手順1〜3を実行します。
アモロソ2018年

回答:


187

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

python manage.py makemigrations your_app_label

ドキュメントでは、アプリラベルをコマンドに追加する必要があることは明らかではpython manage.py makemigrationsありません。最初の移行は、バージョン1.7でアプリを作成したときに行われますが、1.6から移行した場合は実行されません。詳細については、ドキュメントの「アプリへの移行の追加」を参照してください。


1
Django 1.6から来た人たちにいい答えです!ありがとう!
David D.

1
複数のアプリを持っている場合はどうなりますか?私はpython manage.py makemigrations APP_LABELそれぞれに必要がありますか?
Alston

1
ここでDjango 1.9の下で、私のアプリはで作成されましたが./manage.py startapp、ラベルを明示的に言及する必要がありました
maxbellec

50

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

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

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

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

*/migrations/*
!*/migrations/__init__.py

1
プロジェクトのクローンを作成し、migrationsフォルダーがリポジトリにプッシュされなかったため、migrationsディレクターを追加する必要があり、init .py を追加して、移行を行うことができました。ありがとうございました
Junaid

/ migrationsフォルダーの内容を削除して、まだデプロイしていないプロジェクトの設定を「リセット」しました。__init__.py移行とともにフォルダを誤って削除しました。
セス

これは私のためにそれをしました.... You don't have __init__.py file inside migrations folder of those apps. (Solution: Just create an empty file with name __init__.py)..そしてそれはファイルを追加することによって引き起こされました.gitignore
lukik

1
なぜinit .pyファイルがmigrationsフォルダーで非常に重要なのですか?移行を行うには?このロジックをどこで掘り下げることができますか?
Nimish Bansal

1
@NimishBansalまでは、Python 3.3 __init__.pyファイルをディレクトリ内でpythonパッケージとして処理する必要があります。これを参照してください
Mohammed Shareef C

29

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

1.7にアップグレードすると、モデルが管理されなくなりました(managed = False)- True以前と同じように使用しましたが、元に戻されたようです。

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


4
「managed = False」をどこで変更/追加しましたか?同じ問題が発生しています
Ycon、2015年

1
そのコードはもうありませんが、覚えていればクラスのプロパティだと思います。
TyrantWave 2015年

1
いい視点ね。manage.py inspectdbmanage = False を追加することに注意してください!レガシーデータベースをインポートする場合は、慎重にチューニングする必要があります。
アレッサンドロデンテラ2016年

@TyrantWave、あなたは私の日を救った。どうもありがとう。
Utkarsh Sharma

あなたapp_labelが同じであることを確認してください
Luv33preet

19

私のソリューションはここでは取り上げられなかったので、投稿します。私はsyncdbプロジェクトに使用していたのですが、それを立ち上げて実行するためだけのものでした。次に、Djangoの移行の使用を開始しようとすると、最初はそれを偽装し、「OK」であると表示しましたが、データベースには何も起こりませんでした。

私のソリューションは、ちょうど私のアプリのためにすべて移行ファイルを削除し、しただけでなくとしてでアプリの移行のためのデータベースレコードdjango_migrationsのテーブル。

次に、次のようにして初期移行を行いました:

./manage.py makemigrations my_app

に続く:

./manage.py migrate my_app

これで問題なく移行できます。


参考までに、彼がここで「ファイルとデータベースのレコード」と言っていることが重要です データベースレコードを削除したがファイルも削除しなかった場合(を除き__init.py__、機能しません。)
Mike Robinson

15

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

  1. 追加する属性と同様の名前を持つメソッドを削除します。
  2. manage.py makemigrations my_app
  3. manage.py my_appを移行する
  4. メソッドを再度追加します。

11

これは一種の愚かな間違いですが、モデルクラスのフィールド宣言行の最後に余分なカンマがあると、その行は無効になります。

これは、defをコピーして貼り付けると発生します。それ自体が配列として定義されているマイグレーションから。

多分これは誰かを助けるでしょう:-)


1
あなたのコメントは私の問題を見つけるのに役立ちました!選択肢リストの最後の選択肢の最後にコンマがありませんでした。どうやらDjangoは非常に扱いにくいです。
Maxim

1
@Maxim:それはあなたの問題の原因とは考えられませんでした:末尾にコンマが付いていないリストはまだリストです。もう1つの問題はタプルです。タプルに要素が1つしかない場合は、その後にコンマが必要です。
blueFast 2016

時間を節約してくれた男!@dangonfast:モデル定義では、それは確かに問題です。
MrE、2017

11

多分遅すぎmigrationsますが、アプリ内に__init__.pyファイルを含むフォルダを作成しようとしましたか?


1
この「makemigrations」がある場合、アプリの移行が作成されます。それ以外の場合は、makemigrations app_name(これらのファイルを作成する)を実行する必要があります
Scott Warren

7

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


7

答えは、Django 1.7の cdvv7788 Migrationsによるこのstackoverflowの投稿にあります

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

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

manage.py migrateデータベースにアプリがあり、そのモデルを変更し、makemigrationsの変更を更新しない場合、おそらくまだ移行していません。モデルを元の形式に戻し、最初のコマンド(アプリ名を使用)を実行して移行します。偽造されます。これを行ったら、モデルの変更を元に戻し、makemigrationsを実行して再度移行すると、機能するはずです。

私はまったく同じ問題を抱えていて、上記を完全にうまくいきました。

私はdjangoアプリをcloud9に移動しましたが、何らかの理由で最初の移行をキャッチできませんでした。


7

以下は私のために働きました:

  1. アプリ名をsettings.pyに追加します
  2. 「python manage.py makemigrations」を使用します
  3. 「python manage.py migrate」を使用してください

私のために働いた:Python 3.4、Django 1.10


6

移行が嫌いな私のような人は、以下の手順を使用できます。

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

これらの手順のいずれかを混乱させた場合は、移行ファイルをお読みください。それらを変更してスキーマを修正するか、不要なファイルを削除しますが、次の移行ファイルの依存関係の部分を変更することを忘れないでください;)

これが将来誰かを助けることを願っています。


5

あなたはチェックしたいsettings.pyINSTALLED_APPSリストをし、モデルとすべてのアプリケーションは、そこに記載されていることを確認してください。

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


5

makemigrationsによって識別されない特定のフィールドがある場合に備えて、同じ名前のプロパティがあるかどうかを2回確認してください。

例:

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

# ... later

@property
def field(self):
    pass

プロパティはフィールド定義を「上書き」するので、変更は makemigrations


関連する厄介なことは、まだ検証/チェックをエスケープする不正なフィールドを持つことです。私は定義しましたhourly_rate = models.DecimalField(末尾の '()'がありません)、それは静かに失敗しました。
セージ

5

モデルがでないことを確認してくださいabstract。実際に間違えたので時間がかかったので投稿したいと思いました。


4

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

migrationsフォルダーrun makemigrationsとを削除しましたmigrate
それはまだ言いました:適用する移行はありません。

私はmigrateフォルダーに行き、最後に作成されたファイルを開き、必要な
移行にコメントし(検出されてそこに入力されました)
migrate再度実行しました。

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


1
どうもありがとうございます!これは
役に立ち

3

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


10
コマンドはschemamigration存在しません-それは南部の一部だと思いますか?現在、移行フォルダはありません。私models.pyを削除して再inspectdb実行しても何も起こらないようです。
TyrantWave 2014

2
schemamigration南から来ました。makemigrationsその代わりです。
Craig Labenz 2015年

2
これはまだ有効です。しかし、変更されましたmakemigrations --empty
Iulius Curt

2

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

class Product(models.Model):
    title = models.TextField()
    description = models.TextField()
    price = models.TextField()

1

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


1

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

アップグレード後に新しいモデルを追加したとき、makemigrationsコマンドは変更を検出しませんでした。そして、@ drojfによって提案されたソリューションを試してみました(最初の回答)、それはうまくいきましたが、偽の初期移行を適用できませんでした(python manage.py --fake-initial)。テーブル(古いテーブル)が既に作成されているため、これを行っていました。

最後にこれは私にとってmanage.pyうまくいき、models.pyから新しいモデル(またはモデルの変更)を削除してから、すべてのアプリのmigrationsフォルダーを削除(または安全バックアップの名前を変更)し、すべてのアプリに対してpython makemigrationsを実行する必要がありましたpython manage.py migrate --fake-initial。これは魅力のように働きました。すべてのアプリの初期移行が作成され、偽の初期移行が行われると、新しいモデルが追加さmakemigrationsれ、そのアプリの通常のプロセスと移行が行われます。変更が検出され、すべてが正常に行われました。

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


1

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

シリアライザクラスとビューを含む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

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

私を削除し、ステートメントを作成することmodels.pyを期待makemigrationsしましたDeleteModel

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


1
./manage makemigrations
./manage migrate

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

まだ開発モードの場合は、IDEと、モデルに関連するdjango_migrationsテーブルの移行ファイルを削除し、上記のコマンドを再実行することを個人的に決めました。

注意:IDEで_001で終了し、データベースで_003で終了する移行がある場合。Djangoは、何かを更新するために_004で終わる移行があるかどうかのみを確認します。

2(コードとデータベースの移行)はリンクされており、連携して動作します。

ハッピーコーディング。


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

0

上記で利用可能な他のどれも私のために働いていなかったので、この回答を追加しました。

私の場合、何かもっと奇妙が起こっていた(でDjangoの1.7バージョン)、私はmodels.py私が持っていた「余分な」私のファイルの末尾に行を(それが空白行だった)、私は、実行時にpython manage.py makemigrationsコマンドを結果でした。「変更は検出されませんでした」。

これを修正するために、models.pyファイルの最後にあるこの「空白行」を削除し、コマンドを再度実行しました。すべてが修正され、models.pyに加えられたすべての変更が検出されました!


まあdjango 2.0では、空行が必要だと思います。私はあなたが相棒をしたのとは反対のことをしなければなりませんでした
Sumit Kumar Saha

@SumitKumarSaha haha​​私は現在Django 1.7バージョンを使用しています。その空白行が、移行エラーを解決するために2時間すべてを試行した理由です。Sumitを共有していただきありがとうございます。良い一日を
ハスキー、

0

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

python manage.py migrate --fake-initial

0

最初に、このソリューションは、herokuサーバーへの展開中に同じ問題に直面している人に適用できます。私は同じ問題に直面していました。

デプロイするには、django_heroku.settings(locals())をsettings.pyファイルに追加するという必須のステップがあります。

変更:上記の行をdjango_heroku.settings(locals()、databases = False)に変更すると、問題なく動作しました。


0

私の場合、モデルが定義されているmodelsフォルダーの_ init _.pyファイルにモデルを追加する必要がありました。

from myapp.models.mymodel import MyModel

-1

私の2cを追加すると、これらの解決策はどれもうまくいかなかったので、これはうまくいきました...

manage.py squashmigrations古いマイグレーション(django.migrationsデータベーステーブルのファイルと行の両方)を実行して削除したところです。

これにより、最後の移行ファイルに次のような行が残りました。

replaces = [(b'my_app', '0006_auto_20170713_1735'), (b'my_app', '0007_auto_20170713_2003'), (b'my_app', '0008_auto_20170713_2004')]

これは明らかにDjangoを混乱させ、奇妙な振る舞いを引き起こしmanage.py makemigrations my_appました。replaces...行を削除すると問題が解決しました!


-1

python manage.py makemigrations accounts 'accounts'のマイグレーション:accounts \ migrations \ 0001_initial.py-モデルの作成Customer-モデルのタグの作成-モデルの作成Product-モデルの作成Order

注:ここで「アカウント」は私のアプリ名です

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.