Django-makemigrations-変更は検出されませんでした

makemigrationsコマンドを使用して既存のアプリ内に移行を作成しようとしましたが、「変更は検出されませんでした」と出力されます。

通常、startappコマンドを使用して新しいアプリを作成しますが、作成時にこのアプリで使用しませんでした。

デバッグ後、migrationsパッケージ/フォルダーがアプリから欠落しているため、移行を作成していないことがわかりました。

フォルダーがない場合やフォルダーがない場合は、フォルダーを作成した方がよいでしょうか。

アプリの初期移行を作成makemigrationsするには、アプリ名を実行して指定します。migrationsフォルダーが作成されます。

./manage.py makemigrations <myapp>

アプリはINSTALLED_APPS最初に（settings.py内に）含める必要があります。

私の問題（およびそのための解決策）は、上記の問題とはまだ異なりました。

私はmodels.pyファイルを使用していませんでしたが、modelsディレクトリを作成してmy_model.pyそこにファイルを作成し、そこにモデルを配置しました。Djangoは私のモデルを見つけることができなかったので、適用するマイグレーションがないと書きました。

私の解決策は次のとおりです：my_app/models/__init__.pyファイルに次の行を追加しました： from .my_model import MyModel

makemigrationsコマンドの実行中にdjangoが何を移行するかを検出しない場合、いくつかの原因が考えられます。

1. 移行フォルダーアプリに移行パッケージが必要です。
2. INSTALLED_APPSアプリをINSTALLED_APPS.dict で指定する必要があります
3. 冗長makemigrations -v 3性は、冗長性を 実行することから始まります。これは問題にいくつかの光を当てるかもしれません。
4. フル・パスでINSTALLED_APPS、それは完全なモジュールアプリの設定パス「apply.apps.MyAppConfig」を指定することをお勧めします
5. --settings正しい設定ファイルが設定されていることを確認したい場合があります。manage.py makemigrations --settings mysite.settings
6. アプリ名を明示的に指定してアプリ名manage.py makemigrations myappを入力します。これにより、アプリのみの移行が絞り込まれ、問題を特定するのに役立ちます。

7. モデルメタチェックでモデルメタに適切な権限app_labelがある

8. デバッグdjangoデバッグdjangoコアスクリプト。makemigrationsコマンドはかなり単純です。pycharmでそれを行う方法は次のとおりです。それに応じてスクリプト定義を変更します（例：makemigrations --traceback myapp）

複数のデータベース：

• Dbルーター django dbルーターを使用する場合、ルータークラス（カスタムルータークラス）がallow_syncdbメソッドを実装する必要があります。

makemigrationsは常にモデル変更のマイグレーションを作成しますが、allow_migrate（）がFalseを返す場合、

この質問に対する多くの回答を読んだことがあり、makemigrations他の方法で単に実行することを頻繁に述べています。しかし、私にとって、問題はMetaモデルのサブクラスにありました。

私が言うのアプリの設定を持っているlabel = <app name>（にapps.py横に、ファイルmodels.py、views.pyなど）。万が一、メタクラスにアプリのラベルと同じラベルがない場合（たとえば、1つの大きすぎるアプリを複数のアプリに分割しているため）、変更は検出されません（そして役立つエラーメッセージもまったくありません）。だから私のモデルクラスで私は今持っています：

class ModelClassName(models.Model):

    class Meta:
        app_label = '<app name>' # <-- this label was wrong before.

    field_name = models.FloatField()
    ...

ここでDjango 1.10を実行しています。

コメントですが、おそらく答えになるはずです。

アプリ名がsettings.pyにあることを確認してください。INSTALLED_APPSそうでない場合、何をしても、移行は実行されません。

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    'blog',
]

次に実行します：

./manage.py makemigrations blog

ここで説明されていない別の問題が発生しました。

class MyModel(models.Model):
    name = models.CharField(max_length=64, null=True)  # works
    language_code = models.CharField(max_length=2, default='en')  # works
    is_dumb = models.BooleanField(default=False),  # doesn't work

おそらくコピー＆ペーストからの末尾に「、」が1行ありました。is_dumbを含む行は、「./ manage.py makemigrations」を使用したモデルの移行を作成しませんでしたが、エラーもスローしませんでした。「」を削除した後、期待どおりに動作しました。

だからコピー＆ペーストするときは注意してください:-)

アプリ間の特定の競合を処理できるため、./manage.py makemigrationsが優れて./manage.py makemigrations <myapp>いる場合があります。

それらの出来事は静かに起こりswearing、恐ろしいNo changes detectedメッセージの本当の意味を理解するのに数時間かかります。

したがって、次のコマンドを使用する方がはるかに良い選択です。

./manage.py makemigrations <myapp1> <myapp2> ... <myappN>

私はdjangoの外からテーブルをコピーしており、Metaクラスのデフォルトは「managed = false」でした。例えば：

class Rssemailsubscription(models.Model):
    id = models.CharField(primary_key=True, max_length=36)
    ...
    area = models.FloatField('Area (Sq. KM)', null=True)

    class Meta:
        managed = False
        db_table = 'RSSEmailSubscription'

mangedをTrueに変更することにより、makemigrationsは変更を取得し始めました。

1. アプリがsettings.pyのinstalled_appsに記載されていることを確認してください
2. モデルクラスがモデルを拡張していることを確認してください。モデル

私はこれを行うことによってその問題を解決しました：

1. 「db.sqlite3」ファイルを消去します。ここでの問題は、現在のデータベースが消去されるため、再度作成する必要があることです。
2. 編集したアプリのmigrationsフォルダー内で、最後に更新されたファイルを消去します。最初に作成されるファイルは「0001_initial.py」です。例：新しいクラスを作成し、「makemigrations」と「migrate」の手順で登録すると、「0002_auto_etc.py」という新しいファイルが作成されます。それを消去します。
3. " pycache "フォルダー（migrationsフォルダー内）に移動し、ファイル "0002_auto_etc.pyc"を削除します。
4. 最後に、コンソールに移動して、「python manage.py makemigrations」と「python manage.py migrate」を使用します。

私は正しい引数を置くのを忘れました：

class LineInOffice(models.Model):   # here
    addressOfOffice = models.CharField("Корхоная жош",max_length= 200)   #and here
    ...

models.pyで、それからそれはその迷惑を落とし始めました

アプリ 'myApp'で変更は検出されませんでした

別の考えられる理由は、一部のモデルが別のファイル（パッケージではない）で定義されていて、それを他の場所で参照していない場合です。

私にとっては、（新しいファイルがどこにあるか）を追加from .graph_model import *するだけで問題が解決しました。admin.pygraph_model.py

私の問題は上記の回答よりもはるかに単純で、プロジェクトがすでにセットアップされて機能している限り、おそらくはるかに一般的な理由です。長い間動作していた私のアプリケーションの1つでは、移行が不安定に思えたため、急いで次のことを行いました。

rm -r */migrations/*
rm db.sqlite3
python3 manage.py makemigrations
No changes detected

えっ？

私は誤ってすべての__init__.pyファイルも削除していました:(-行ってからすべてが再び機能していました：

touch ads1/migrations/__init__.py

私のアプリケーションのそれぞれについて、makemigrations再び動作しました。

別のアプリケーションをコピーして新しいアプリケーションを手動で作成し、__init__.pyそのmigrationsフォルダーにフォルダーを配置するのを忘れていたことがわかりました。これにより、すべてが不安定であることがわかりましたrm -r。

これにより、「変更が検出されませんでした」というエラーが数時間にわたって発生するのを防ぐことができます。

解決策は、アプリをINSTALLED_APPSに含める必要があることです。

私はそれを逃しました、そして私はこの同じ問題を見つけました。

アプリ名を指定した後、移行が成功した

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'boards',
]

最後にボードについて言及しましたが、これは私のアプリ名です。

INSTALLED_APPS = [

'blog.apps.BlogConfig',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',

]

「blog.apps.BlogConfig」を確認します（これは、アプリの移行を行うために、settings.pyに含まれています）。

次に、python3 manage.py makemigrationsブログまたはアプリ名を実行します

あなたが持つことができる非常にばかげた問題class Metaは、モデルで2つを定義することです。その場合、を実行しても、最初の変更に対する変更は適用されませんmakemigrations。

class Product(models.Model):
    somefield = models.CharField(max_length=255)
    someotherfield = models.CharField(max_length=255)

    class Meta:
        indexes = [models.Index(fields=["somefield"], name="somefield_idx")]

    def somefunc(self):
        pass

    # Many lines...

    class Meta:
        indexes = [models.Index(fields=["someotherfield"], name="someotherfield_idx")]

私はこれが古い質問であることを知っていますが、私はこれと同じ問題で一日中戦っており、私の解決策は単純なものでした。

私は自分のディレクトリ構造を何かに沿って持っていました...

apps/
   app/
      __init__.py
      app_sub1/
           __init__.py
           models.py
      app_sub2/
           __init__.py
           models.py
      app_sub3/
           __init__.py
           models.py
   app2/
      __init__.py
      app2_sub1/
           __init__.py
           models.py
      app2_sub2/
           __init__.py
           models.py
      app2_sub3/
           __init__.py
           models.py
    main_app/
      __init__.py
      models.py

そして、私が問題を抱えたモデルまでの他のすべてのモデルは、どこかにインポートされていて、最終的main_appにはに登録されたモデルからインポートされてINSTALLED_APPSいたので、すべてが動作して幸運でした。

私はそれぞれを追加しましたので、しかしappにINSTALLED_APPSしていないapp_sub*私は最終的にどこにも輸入されていなかった新しいモデルのファイルを追加したとき、Djangoは完全にそれを無視しました。

私の修正は、このようなmodels.pyそれぞれのベースディレクトリにファイルを追加することでしたapp...

apps/
   app/
      __init__.py
      models.py <<<<<<<<<<--------------------------
      app_sub1/
           __init__.py
           models.py
      app_sub2/
           __init__.py
           models.py
      app_sub3/
           __init__.py
           models.py
   app2/
      __init__.py
      models.py <<<<<<<<<<--------------------------
      app2_sub1/
           __init__.py
           models.py
      app2_sub2/
           __init__.py
           models.py
      app2_sub3/
           __init__.py
           models.py
    main_app/
      __init__.py
      models.py

次に、from apps.app.app_sub1 import *各appレベルmodels.pyファイルに追加します。

Bleh ...これを理解するのにとても時間がかかり、どこにも解決策を見つけることができませんでした... Googleの検索結果の2ページ目にも行きました。

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

公式ドキュメントの移行セクションによると、私はdjango 3.0で同様の問題があり、これを実行するとテーブル構造を更新するのに十分でした：

python manage.py makemigrations
python manage.py migrate

しかし、出力は常に同じでした。「makemigrations」スクリプトを実行した後、モデルに関する「変更は検出されませんでした」。私はdbで更新したいモデルでmodels.pyに構文エラーがありました：

field_model : models.CharField(max_length=255, ...)

の代わりに：

field_model = models.CharField(max_length=255, ...)

この愚かな間違いを解決し、それらのコマンドで移行は問題なく行われました。多分これは誰かを助ける。

あなたは追加する必要がありますpolls.apps.PollsConfigにINSTALLED_APPSでsetting.py

私の場合、クラス引数を挿入するのを忘れました

違う：

class AccountInformation():

正しい

class AccountInformation(models.Model):

私の場合、最初にモデルにフィールドを追加しましたが、Djangoは変更はないと言いました。

モデルの「テーブル名」を変更することに決めたよりも、メイクマイグレーションがうまくいきました。テーブル名をデフォルトに戻したところ、新しいフィールドもそこにありました。

django移行システムには「バグ」があり、新しいフィールドが表示されない場合があります。日付フィールドに関連している可能性があります。

考えられる理由は、既存のdbファイルとpythonを使用して移行できるフォルダーの削除である可能性があり、manage.py makemigrations <app_name>これは機能するはずです。私はかつて同様の問題に直面しました。

もう1つのエッジケースとソリューション：

私はブールフィールドを追加し、同時にそれを参照する@propertyを同じ名前（doh）で追加しました。プロパティにコメントし、移行により新しいフィールドが表示および追加されます。プロパティの名前を変更し、すべてが良いです。

managed = Trueintモデルのメタがある場合は、それを削除して移行を行う必要があります。その後、移行を再度実行すると、新しい更新が検出されます。

新しいモデルをdjango apiアプリケーションに追加して実行するとpython manage.py makemigrations、ツールは新しいモデルを検出しませんでした。

奇妙なことに、古いモデルはによって選択されましたmakemigrationsが、これは、それらがurlpatternsチェーンで参照され、ツールが何らかの方法でそれらを検出したためです。したがって、その動作に注意してください。

問題は、モデルパッケージに対応するディレクトリ構造にサブパッケージがあり、すべての__init__.pyファイルが空だったためです。ツールでDjangoが取得できるように、各サブフォルダーとモデル __init__.pyに必要なクラスをすべて明示的にインポートする必要がありmakemigrationsます。

models
  ├── __init__.py          <--- empty
  ├── patient
  │   ├── __init__.py      <--- empty
  │   ├── breed.py
  │   └── ...
  ├── timeline
  │   ├── __init__.py      <-- empty
  │   ├── event.py
  │   └── ...

モデルをadmin.pyに登録してみてください。例は次のとおりです：-admin.site.register（YourModelHere）

次のことを行うことができます。-1. admin.site.register（YourModelHere）＃admin.pyで2.ページをリロードして再試行します3. CTRL-Sを押して保存します4.エラーが発生する可能性があります。特にモデルを確認してください.pyおよびadmin.py 5.または、最後にサーバーを再起動します。

私はこれを追い払うために何時間も費やしてしまったので、これはうまくいけば他の誰かを助けるかもしれません。

モデル内に同じ名前の関数がある場合、これにより値が削除されます。後から見るとかなり明白ですが、それにもかかわらず。

したがって、次のような場合：

class Foobar(models.Model):
    [...]
    something = models.BooleanField(default=False)

    [...]
    def something(self):
        return [some logic]

その場合、関数は上記の設定をオーバーライドし、に「非表示」にしmakemigrationsます。

あなたができる最善のことは、既存のデータベースを削除することです。私の場合、phpMyAdmin SQLデータベースを使用していたため、作成したデータベースを手動で削除しました。

削除後： 私はPhpMyAdminでデータベースを作成し、テーブルを追加しません。

次のコマンドを再度実行します。

python manage.py makemigrations

python manage.py migrate

これらのコマンドの後：djangoが他の必要なテーブルをデータベースに自動的に作成したことがわかります（約10個のテーブルがあります）。

python manage.py makemigrations <app_name>

python manage.py migrate

そして最後に：上記のコマンドの後、作成したすべてのモデル（テーブル）がデータベースに直接インポートされます。

これがお役に立てば幸いです。

このエラーの私の問題は、私が含めていたことでした：

class Meta:
   abstract = True

創作移行したかったインサイドモデル。

という新しいアプリを作成しているときに別の問題が発生しましたdeals。そのアプリ内のモデルを分離したかったのでdeals.py、およびという名前の2つのモデルファイルを用意しましたdealers.py。実行するpython manage.py makemigrationsと私は得ました：No changes detected。

私は先に行き__init__.py、モデルファイルが住んでいたのと同じディレクトリ（取引とディーラー）にある内に行きました

from .deals import *
from .dealers import *

そして、makemigrationsコマンドは機能しました。

モデルをどこにもインポートしていない場合、またはモデルのファイル名がインポートされていないmodels.py場合、モデルは検出されないことがわかります。

私に起こった別の問題は、私がアプリを書いた方法ですsettings.py：

私が持っていた：

apps.deals

ルートプロジェクトフォルダーが含まれているはずです。

cars.apps.deals