タイトルが言うように、私は移行がうまくいくようには思えません。
このアプリはもともと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.7にアップグレードすると、私のモデルは管理されなくなりました(managed = False
) - 以前はTrue
としていましたが、元に戻されたようです。
その行を削除し(デフォルトはTrue)、それからmakemigrations
を実行するとすぐに移行モジュールが作成され、動作します。 makemigrations
は、管理されていないテーブルでは機能しません(これは後知恵で明らかです)。
Django 1.6で作成した既存のアプリから切り替える場合は、ドキュメントに記載されている1つの事前手順(私が見つけたように)を実行する必要があります。
python manage.py makemigrationsyour_app_label
最初にやらなければならないことはpython manage.py makemigrations
で、これは失敗するので、ドキュメントはあなたがコマンドにappラベルを追加する必要があることを明白にしません。最初の移行は、バージョン1.7でアプリを作成したときに行われますが、1.6から来た場合は実行されませんでした。詳しくは、ドキュメントの 'アプリへの移行の追加' をご覧ください。
これは、以下の理由により発生する可能性があります。
INSTALLED_APPS
のリストsettings.py
に追加しませんでした(あなたはDjangoのバージョンに応じて、アプリ名またはappフォルダのapps.pyにあるAppConfigのサブクラスに点線のパスを追加します。を使用して)。ドキュメントを参照してください。 INSTALLED_APPSmigrations
フォルダを持っていません。 (解決策:そのフォルダを作成するだけです)。migrations
フォルダー内に__init__.py
ファイルはありません。 (解決策:__ init __。pyという名前の空のファイルを作成するだけです)__init__.py
ファイルがありません。 (解決策:__ init __。pyという名前の空のファイルを作成するだけです)models.py
ファイルがありませんmodels.py
のあなたのPythonクラス(モデルであるはず)は継承しませんDjango.db.models.Model
models.py
でモデルの定義に意味上の誤りがあります。注:よくある間違いは、.gitignore
ファイルにmigrations
フォルダーを追加することです。リモートリポジトリからクローンを作成すると、migrations
フォルダや__init__.py
ファイルがローカルリポジトリに表示されなくなります。これは問題を引き起こします。
.gitignore
ファイルに次の行を追加して、移行ファイルを無視することをお勧めします。
*/migrations/*
!*/migrations/__init__.py
私の解決策はここではカバーされていないので、私はそれを投稿しています。私はsyncdb
をプロジェクトのために使っていました - ちょうどそれを立ち上げて実行するためです。それから私がDjangoのマイグレーションを使い始めようとしたとき、最初はそれらを偽造していましたが、それは 'OK'と言っていましたが、データベースには何も起こりませんでした。
私の解決策は、Django_migrations
テーブルのアプリ移行のデータベースレコードとして、私のアプリのすべての移行ファイルとを削除することでした。
それから私はちょうど最初の移行をしました:
./manage.py makemigrations my_app
に続く:
./manage.py migrate my_app
今私は問題なく移行を行うことができます。
@furinsに同意してください。すべてが順調に進んでいても問題が発生する場合は、Modelクラスに追加しようとしている属性と同じタイトルのプロパティメソッドがあるかどうかを確認します。
これは愚かなミスですが、モデルクラスのフィールド宣言行の末尾に余分なカンマを追加しても、その行は無効になります。
あなたがdefをコピーペーストするときに起こります。それ自体が配列として定義されているマイグレーションから。
多分これは誰かに役立つだろう:-)
遅すぎるかもしれませんが、__init__.py
ファイルを含むmigrations
フォルダーをアプリに入れようとしましたか?
以下は私のために働いた:
私のために働きました:Python 3.4、Django 1.10
答えはcdvv7788によるこのstackoverflow記事にあります Django 1.7での移行
それがあなたがそのアプリを移行しているのは初めての場合はあなたが使用する必要があります。
manage.py makemigrations myappnameこれを実行したら、次のことができます。
manage.py migrateデータベースにアプリがある場合は、モデルを変更し、makemigrationsの変更が更新されない場合は、まだ移行していない可能性があります。モデルを元の形式に戻し、最初のコマンドを(アプリ名を付けて)実行して移行します。それを行ったら、モデルへの変更を元に戻して、makemigrationsを実行し、再度移行してください。これでうまくいくはずです。
私は全く同じ悩みを抱えていて、上記をすることは完全にうまくいきました。
私は自分のDjangoアプリをcloud9に移行しましたが、何らかの理由で私は最初の移行に気付きませんでした。
私のようにマイグレーションが好きでない人は、以下のステップを使うことができます。
python manage.py makemigrations app_label
を実行してください。python manage.py migrate
を実行してテーブルを作成してください。これらの手順のいずれかを混同した場合は、移行ファイルを読んでください。スキーマを修正するか不要なファイルを削除するように変更してください。ただし、次の移行ファイルの依存関係の部分を忘れずに変更してください。
これが将来誰かに役立つことを願っています。
多分これは誰かを助けるでしょう。入れ子になったアプリを使用していました。 project.appnameと私は実際にはINSTALLED_APPSにprojectとproject.appnameがありました。 INSTALLED_APPSからプロジェクトを削除すると、変更を検出できました。
settings.py
リストのINSTALLED_APPS
をチェックして、モデルを含むすべてのアプリがそこにリストされていることを確認します。
プロジェクトフォルダでmakemigrations
を実行すると、プロジェクトのsettings.py
に含まれるすべてのアプリに関連するすべてのテーブルが更新されるようになります。含めると、makemigrations
が自動的にアプリを含めます(これにより多くの作業が節約されるので、プロジェクト/サイト内のすべてのアプリに対してmakemigrations app_name
を実行する必要はありません)。
念のため、makemigrationsで識別されない特定のフィールドがある場合は、同じ名前のプロパティがあるかどうかを2回チェックします。
例:
field = Django.db.models.CharField(max_length=10, default = '', blank=True, null=True)
# ... later
@property
def field(self):
pass
プロパティはフィールド定義を「上書き」するため、変更はmakemigrations
によって識別されません。
この方法だけが私を助けたので、この答えを追加しました。
migrations
とmakemigrations
を実行して、migrate
フォルダーを削除しました。
まだ言っています:移行する必要はありません。
migrate
フォルダに行き、最後に作成したファイルを開きました、
欲しい移行についてコメントします(検出され、そこで入力されました)
そしてmigrate
をもう一度実行してください。
これは基本的に手動でマイグレーションファイルを編集することです。
ファイルの内容を理解している場合にのみこれを実行してください。
モデルがabstract
ではないことを確認してください。私は実際にその間違いをしました、そしてそれはしばらく時間がかかりました、それで私はそれを掲示すると思いました。
古い移行フォルダの名前を変更した後にschemamigration my_app --initial
を使用しましたか?それを試してみてください。うまくいくかもしれません。そうでない場合 - データベースを再作成してsyncdb + migrateを実行してください。それは私のために働きました...
多分それは誰かを助けることができる、私は同じ問題を抱えていた。
シリアライザクラスとビューを使って2つのテーブルを作成しました。だから私が更新したいと思ったとき、私はこのエラーがありました。
私はこの手順に従った:
.\manage.py makemigrations app
を作りました.\manage.py migrate
を実行しましたmodels.py
の両方のテーブルを消去しました1
と2
を実行しました。models.py
で私の変更を取得しました5
をもう一度実行しました。あなたがPycharmを使っているのなら、地元の歴史はとても役に立ちます。
私は2回makemigrationsを実行しなければならないことと同じような問題を抱えていました、そしてあらゆる種類の奇妙な行動。問題の根本は、私が自分のモデルにデフォルトの日付を設定するために関数を使っていたので、マイグレーションがmakemigrationsを実行するたびに変更を検出していたことです。この質問への答えは私を正しい軌道に乗せました: 日付フィールドを再作成するためのmakemigrationsを避けます
私は最近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
を持つ)、それはそれらを助けるかもしれません:)
同じ問題がありました models.pyで定義したクラスがなんであれ、models.Modelクラスを継承する必要があることを確認してください。
class Product(models.Model):
title = models.TextField()
description = models.TextField()
price = models.TextField()
./manage makemigrations
./manage migrate
移行によってDBへの変更が追跡されるため、管理対象外から管理対象に変更する場合は、対象となるモデルに関連するデータベーステーブルが最新であることを確認する必要があります。
それでもdevモードの場合は、IDEと私のモデルに関連するDjango_migrationsテーブルの移行ファイルを個人的に削除して、上記のコマンドを再実行することにしました。
注意:データベースのIDE&_003に_001で終わる移行がある場合。 Djangoは更新するものが何であれ_004で終わる移行があるかどうかだけを見ます。
2(コードとデータベースの移行)はリンクされており、連携して機能します。
ハッピーコーディング.
多分これは誰かを助けるでしょう。
私は私のmodels.py
を削除し、makemigrations
ステートメントを作成するためにDeleteModel
を期待しました。
*.pyc
ファイルを削除することを忘れないでください。
上記の他に利用可能なものがどれも私のために働かなかったのでこの答えを加えた。
私の場合はさらに奇妙なことが起こっていました(Django 1.7バージョン)、私のmodels.py私のファイルの最後に "extra"の行がありました(それは空白行でした)そしてpython manage.py makemigrations
を実行した時 "変更は検出されませんでした"
これを修正するために、私はこの "空白行"を削除しました。これは私のmodels.pyファイルと私は再びコマンドを実行しました、すべてが修正され、models.pyに加えられたすべての変更が検出されました!
以下のコマンドを使用して、初期移行を偽造する必要がある場合があります
python manage.py migrate --fake-initial