問題タブ [schema-migration]

South manage.py schemamigration によって生成されたすべての移行ファイルには、通常、south.v2.SchemaMigration のサブクラスがあります。このクラスには forwards() および backwards() メソッドとモデル属性が含まれます。South はモデル属性をどのように使用しますか?

同じ Django アプリであまりにも多くのモデルを作成するというばかげた間違いを犯したため、3 つの異なるモデルに分割したいと考えています。問題は、2 つの顧客のサイトで既に運用中のデータがあるため、実行するスキーマ/データの移行を慎重に計画する必要があることです (私は django-south を使用しています)。どのように進めたらよいかわからないので、アドバイスをいただければ幸いです。

（関係がある場合は、Ubuntuサーバー12.4 LTSでPostgreSQLを使用しています）

を使用することを考えましdb.rename_tableたが、外部キーをこれらのモデル (古いものから新しいものへ) に正しく更新する方法がわかりません - データベース レベルでは関係ありません (テーブルの名前変更は既にカバーされているため) が、ORM レベルではそうではありません.

更新: それについて考えた後、 programmmers.SE でこの質問をした後、物事をシンプルに保ち、製品のメジャー バージョン間の移行について心配しないことにしました。短期的には、モデルを古いアプリに保持しながら、ダニエル・ローズマンが提案したようにdb.rename_table使用しながら、新しい名前に一致させるために使用します。db_tableメジャー バージョンにアップグレードするときは、新しいアプリに切り替えて、すべての移行を完全に破棄します (そのため、新しいバージョンを新しくインストールすると、過去のすべての移行を行うのではなく、データベースが「そのまま」作成されます)。

私はこの問題をローカルで解決することに成功しました：

移行ファイルがありません

しかし、現在Herokuで偉業を複製しようとしており、そこでデータベースにアクセスする方法がわかりません。誰かが私にプロセスを案内してもらえますか？

私はしばらくの間herokuでDjangoプロジェクトを実行していますが、ツリーの数日前にスキーマモデルを更新しようとしましたが、書くたびに

heroku はすべてが最新であると言い続けますが、models.py フォルダーを変更し、いつものようにスキーマの移行を実行しました。

なぜこれが起こっているのか、またはherokuアプリにスキーマを強制的に移行する方法を知っている場合は、その方法を教えてください.

Ps: heroku に保存されているデータとローカル サーバー データベースに保存されているデータが同じではないため、hole データベースを削除できません。また、ユーザーのデータを失いたくないのです。

スキーマの移行を実行できるように、アプリへのユーザーアクセスを無効にしたいのですが。私はいくつかの可能性を調べ、考えられる欠点を見つけました。

1. データストアの書き込みを無効にする-アプリケーション全体を停止して、エラーなどが表示されないようにします。また、書き込みを無効にすると、移行を実行できなくなると思います。

2. アプリケーションを無効にする-これによってユーザーに対してのみアプリケーションが無効になり、移行を実行できなくなるかどうかはわかりません。また、無効化/有効化の所要時間もわかりません。

3. ドメイン名を一時ページにリダイレクトします-私のアプリは引き続きappspot.comからアクセスできます

4. 「一時的にダウンした」ページに移動する以外のリクエストに応答しない新しいバージョンのアプリをアップロードします。

助言がありますか？

UIManagedDocumentCore Data を使用しているときに、オブジェクトがdocumentState5 に等しいことがわかりました。UIDocumentドキュメントでは、次の定数のみが定義されています。

これは、0、1、2、4、および 8 になります。5 は、をUIManagedDocument使用する特別な状態である可能性がありますが、どこにも文書化されていません。Core Data スキーマが変更されると、この状態が発生するようです。状態の意味がわかりません。通常、エラー: が表示Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'This NSPersistentStoreCoordinator has no persistent stores. It cannot perform a save operation.'されます。永続ストアとして使用するには、ドキュメントを通常の状態で開く必要があるため、これは理にかなっています。

現在、状態が 5 であることを確認し、永続ストアを削除して、これが発生したときに再作成しています。しかし、アプリがライブになり、ユーザー データが保存されるようになると、このようなことはしたくありません。コア データ スキーマを移行するためのベスト プラクティスについては調べていませんがmanagedDocument.documentState == 5、コードでチェックするのもややこしいようです。このドキュメントの状態に関するドキュメントはどこにもありませんか?

更新:今見てみると、これらの定数がこのように定義されている理由は、マスクとしてビットごとに ored できるようにするためであることが理にかなっています。したがって、documentState5 に等しいということは、それが と の両方であることを意味しUIDocumentStateClosedますUIDocumentStateSavingError。ただし、これらのエラーはかなり一般的です。根本原因を絞り込むにはどうすればよいですか？

また、これらのドキュメントの状態をチェックするために私が見たすべてのサンプル コードは、等しいif (managedDocument.documentState == UIDocumentStateClosed)かどうかのチェックを示していますif (managedDocument.documentState & UIDocumentStateClosed)。

私のジャンゴアプリでは、datetimefield を datefield に変換したいと考えています。その結果、エラーが発生しました:

これを行う方法を教えてください。

私はこれを試しました：

datetimefield の値を datetime から date に変更する schemamigration の前に datamigration を作成しました。

コマンドを使用してスキーマを更新しようとしていますapp/console doctrine:schema:update --forceが、Doctrine は次の部分で失敗します:

これは、別の SO questionに従って解決するのは簡単です。テーブルには次のものがあります。

したがって、これは一致する制約を削除することで手動で解決できます。しかし、それを自動的に行う方法はありますか？

ROR、Django などの新しい Web フレームワークはすべて、アジャイルと TDD の一般原則に従っていると聞いています。アジャイルと TDD に従うことの 1 つの部分は、ある反復から別の反復に進むときに独自の設計を作成することです。これは、モデルとそのスキーマがアプリのさまざまなバージョンで進化することを意味します。ROR がスキーマの移行をネイティブにサポートしていることは知っていますが、django についてはわかりません。私の主な関心事は、スキーマに関連するすべての問題を事前にどのように決定できるかということです。ウォーターフォールのようなデザイン哲学に戻っているのではないでしょうか。

また、スキーマ移行用の「south」などの外部パッケージがあることも知っています。しかし、この質問は、なぜdjangoがRORのような移行をネイティブにサポートしていないのかについての質問です.