問題タブ [django-migrations]

一部の権限を更新するデータ移行があります。移行のアクセス許可にはいくつかの既知の問題があることを知っており、移行自体でアクセス許可を作成することで (モデルでタプル ショートカットを使用するのではなく)、いくつかの問題を回避できました。

移行:

いくつかの試行錯誤の後、私はこれを使用して機能させることができましたmanage.py migrateが、テストでエラーが発生していますmanage.py test。

ContentTypeテストで実行すると、移行のこの時点で何もないことが少し発見されました（理由はわかりません）。この投稿のアドバイスに従って、移行自体でコンテンツ タイプを手動で更新しようとしました。追加した ：

Invitationモデルのコンテンツ タイプを取得する前。次のエラーが発生しました

テスト可能な方法でデータ移行の権限を作成/更新する何らかの方法が必要です。

ありがとう。

編集

最後に追加して機能させました

奇妙なことに、これは十分ではありませんでした

なぜこれがすべて必要なのか知りたいです

カスタム ユーザー モデルへの ForeignKey を持つ新しいモデルの移行を実行すると、次のエラーが発生します。

それはDjango 1.7にあります。

私のカスタム ユーザーはapps.models.EmailUserです。

関連するコードは次のとおりです。

最後に、移行ファイルは次のとおりです。

完全なエラー トレースバック

追加情報

django.db.migrations.state.render() でカスタム ユーザー モデルを使用しているかどうかを確認するテストがあることに気付きましたが、render が ignore_swappable=True で呼び出された場合にのみ、このテストを真剣に受け止めます。私の場合。

アイデアはありますか？

だから私は最近、南からネイティブの Django への移行にジャンプしました。移行の移行はすべてスムーズに進みましたが、最近の変更のいくつかはうまくいきませんでした。

私はこのようにモデルを持っていました:

私はこれに変更しました：

この変更は によって取得されていませんが、フィールド./manage.py makemigrationsに があり、空白のままで のインスタンスをNOT NULL作成できないことを意味します。次のように表示されます。MyModelf1

私に何ができる？MySQL バックエンドを使用しています。

質問でその問題について確認しましたが、移行での Django ビルドに関する簡単な説明が見つかりませんでした。または、十分に信頼できますか?

Django 1.7 で新しいプロジェクトを開始しましたが、ビルドの移行で多くの問題に直面しています。南部では普通だった単純なことは、そのバージョンでは例外になります。たとえば、charfield をforeignkey に変更すると、フィールド タイプを int にキャストできないというエラーが発生します。これは正常なことであり、それが移行を行っている理由です。以前のプロジェクトで South で何をしなければならなかったかを知っているので、django の移行がそのような操作を処理することを強く疑っていますか? たとえば、カスタムフィールドのイントロスペクション、外部キーの多対多への変換、抽象クラスのフィールドへの変更、その他多くの...だから私の質問は次のとおりです。

Django 1.7 ビルドの移行は、複雑で正規化されたデータベース構造に対して十分に信頼できますか?

PS少なくとも南と同じくらい強力です（問題がそれらの使用にある場合は処理しますが、プロジェクトの準備ができており、データベースに多くのレコードがあり、変更する必要がある状況に陥りたくありませんテーブルの削除やその他の危険な操作を必要とするもの)。

アプリケーションでいくつかの動的 Django モデルを作成していますが、移行システムを除いてすべてが期待どおりに機能しているようです。

動的 Django モデルを作成して managed = False に設定すると、Django のmakemigrationsコマンドは引き続きその新しいモデルの移行を生成します。移行は次のようになります。

移行を作成しない場合、 を実行するpython manage.py migrateと、次のメッセージが表示されます (大きな恐ろしい赤い文字で)。

Django 1.7 の移行システムに、管理されていないモデルをすべて無視するように指示する方法はありますか? それともmigrations = False、モデルの Meta クラスの設定でしょうか?

更新:明確にするために、次の場所で説明されているものと同様の動的モデルを作成する方法を使用しています。

• http://dynamic-models.readthedocs.org/en/latest/topics/model.html#topics-model
• https://code.djangoproject.com/wiki/DynamicModels

この方法は、構成モデル ( https://code.djangoproject.com/wiki/DynamicModels#Adatabase-drivenapproach )に格納されている情報に基づいて動的モデルを生成するのに最適です。構成インスタンスが変更されたときにモデルへの変更をキャッチするために、django モデル キャッシュをクリアするシグナルを登録する必要がありましたが、これらのモデルの移行が生成されるという事実を除いて、すべてがうまく機能しているようです。構成の 1 つを削除し、モデルが Django のキャッシュから削除された場合、移行を再度更新して、気にする必要のないモデルを削除する必要があります。

これらの動的モデルは、アプリケーションでは特に使用されません。コードのどこで book モデルを参照していませんか (上記の例から)。それらは実行時に生成され、アクセスを提供する従来のテーブルから情報を読み取るために使用されます。

1.7 の移行 (postgres 9.1 - 私の環境の詳細が必要な場合はお知らせください) を使用して Django アプリのモデルへの変更を同期しようとしていますが、manage.py migrate は何もしていないようで、sqlmigrate SQL を出力しません。

Django 1.7 - makemigrationsの後に migrate を実行すると「No migrations to apply」が私の状況に適用される可能性があると考えましたが、データベースの django_migrations テーブルにいくつかの履歴が見つかりました。移行しようとしているアプリのレコードを削除しました。

最近、alter table ステートメントを生成/実行することをあきらめ、元のバージョンのテーブルを削除しました。そして、manage.py migrate は移行を適用していると述べていますが、データベースには何も起こりません。

私が試してきた手順は次のとおりです。

履歴を削除します。

初期移行を作成します。

manage.py migrate は次を返します。

次に、新しいモデルを交換して、新しい移行を生成します。

makemigrations の結果は myapp/migrations/0002_notificationlog.py にあります。

この移行を実行します。

manage.py migrate はすべて問題ないように動作します。

django_migrations にログ エントリが表示されているのがわかりますが、テーブルは作成されていません。

道に迷いました。次に何を試してみますか？

アップデート

要求に応じて migrate -v 3 を実行すると、

インストールされているアプリごとに同様の行が続きます。

それで

合計 13 回繰り返し、管理されていないアプリの数です。

それで

に続く

インストールされているアプリごとに同様の行があります。

移行 0002 の場合、出力は同じですが、次の点が異なります。

また、sqlmigrate も何も出力しないことに注意してください。

まったく何も生み出しません。

更新 2

myapp を新しいプロジェクトにコピーして移行を実行できましたが、メイン プロジェクトの設定をインポートすると移行が機能しなくなりました。特に Django の以前のバージョンで South を使用している場合、移行の実行に影響を与える可能性があることに注意する必要がある設定はありますか?