148

タイトルが示すように、移行が機能していないようです。

アプリはもともと 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のものです。

4

32 に答える 32

193

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

python manage.py makemigrations your_app_label

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

于 2014-09-15T07:55:53.937 に答える
30

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

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

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

于 2014-07-24T09:07:38.240 に答える
21

私の解決策はここではカバーされていなかったので、投稿しています。私はsyncdbそれを起動して実行するためだけに、プロジェクトに使用していました。次に、Django 移行の使用を開始しようとすると、最初はそれらを偽造し、「OK」と表示されましたが、データベースには何も起こりませんでした。

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

次に、次の方法で最初の移行を行いました。

./manage.py makemigrations my_app

に続く：

./manage.py migrate my_app

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

于 2015-01-23T06:47:33.450 に答える
15

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

  1. 追加する属性と同じ名前のメソッドを削除します。
  2. manage.py makemigrations my_app
  3. manage.py 移行 my_app
  4. メソッドを追加し直します。
于 2016-01-30T07:27:22.983 に答える
13

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

デフをコピーペーストすると発生します。それ自体が配列として定義されている移行から。

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

于 2015-10-12T13:19:29.993 に答える
7

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

于 2015-04-09T01:40:02.083 に答える
7

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

  1. アプリ名を settings.py に追加します
  2. 「python manage.py makemigrations」を使用
  3. 「python manage.py 移行」を使用

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

于 2016-10-26T06:34:07.630 に答える
6

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

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

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

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

于 2015-12-09T00:36:52.330 に答える
5

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

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

于 2015-06-14T01:26:48.630 に答える
5

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

migrationsフォルダ runmakemigrationsとを削除しましたmigrate。
それはまだ言った：適用する移行はありません。

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

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

于 2016-07-10T13:03:18.110 に答える
5

モデルが ではないことを確認してくださいabstract。私は実際にその間違いを犯し、しばらく時間がかかったので、投稿しようと思いました.

于 2016-11-15T15:49:44.723 に答える
1

makemigrations を 2 回実行する必要があり、あらゆる種類の奇妙な動作が発生するという同じ問題がありました。問題の根本は、関数を使用してモデルにデフォルトの日付を設定していたため、makemigrations を実行するたびに移行が変更を検出していたことが判明しました。この質問への答えは、私を正しい軌道に乗せました:日付フィールドを再作成するためにmakemigrationsを避けてください

于 2014-12-11T20:21:18.200 に答える
1

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

python manage.py migrate --fake-initial
于 2019-08-15T13:04:48.350 に答える
0

原因の 1 つは、モデルを admin.py ファイルに登録していない可能性があります。最初にモデルを admin.py ファイルに登録してから、移行を行います。

于 2021-09-23T06:20:09.753 に答える