問題タブ [legacy-database]

背景情報: 私は django の初心者であり、python の知識が豊富で、mysql (したがって mariaDB) の初心者でもあります。次のバージョンの Windows 7 環境で作業しています。

• ジャンゴ1.9.1
• マリアDB 10.0.20
• パイソン 3.4.4
• Python 3.4 の場合は mysql-connector\Python 2.1.3

目標: django を使用して、mariaDB データベースと Web ベースのユーザー インターフェイスを構築しようとしています。mysqlで事前にデータベースを構築しており、現在、このデータベースをレガシーデータベースとして使用してdjangoプロジェクトを作成しようとしています.

問題: 次のようにモデルを django プロジェクトに取得しました。

そしてそれはうまくいきました。models.py もチェックしましたが、問題ないように見えました。

ここで、次のように、django に基づいてレガシー データベースにテーブルを作成するために移行しようとすると、次のようになります。

ネストされたエラーがたくさん発生し続けます。最後のエラーは次のとおりです。

前回の試行でテーブルがデータベース フォルダに残っていると考えましたが、削除しても役に立ちません。データベースのコマンド プロンプトから、残っている唯一のテーブルがデータベースにネイティブであることを確認しても、同じエラー メッセージが表示されます。ある時点で、推奨されているコネクタ (mysqlclient) ではないため、使用しているコネクタに問題があるのではないかと考えました。

どこかで、移行さえ必要ないことがわかりました。これは明らかに私を救うでしょうが、それが私ができる解決策であるかどうかはわかりません. 理想的には、データベースは後でオンラインで管理され、管理者アカウントを持つユーザーはそこにエントリを追加できます。それ以外の場合、データベースはデータを返すだけです。

編集: python manage.py inspectdb > models.py 行のエラー メッセージを修正しました

編集29.1。 移行を次のように実行します。

同じエラーが発生します。

django プロジェクトを削除して新たに開始した後でも、問題は解決しません。

v2 29.1 を編集します。 データベース フォルダー内の django_migrations テーブルに必要なテーブル ファイルは 1 つだけです。django_migrations.ibd と django_migrations.frm があるはずです。ただし、移行を実行すると、django_migrations.ibd というファイルが 1 つだけ残ります。

ここで同様のことが起こっていましたが、別のファイル mysqldump の問題で、復元エラー: 'Please DISCARD the tablespace before IMPORT' が発生しました。選択した回答でよく説明されています。

これは私の問題に関連していると思いますが、何が助けになり、これをどうするべきかわかりません。

v3 29.1 を編集します。 そして最後に、ファイルがdjangoエラーを出していることに気付きました。59 行目の C:\Python34\lib\site-packages\django\db\migrations\recorder.py にある django の移行レコーダーです。

エラーが発生する最後の行は 59 行目です。おかしなことに、テーブルが存在する場合、関数は機能するはずです。（以前の編集のように）私が思いつくことができる唯一のことは、実際には何らかの理由で移行プロセス中にfrmファイルが作成されないことです。

なぜそれが起こるのかは、私をはるかに超えています。

django を使用しているときにレガシー データベース (managed=False) からデータをダンプしようとすると、このエラー メッセージが表示されます。

python manage.py dumpdata --database legacy_db

CommandError: データベースをシリアル化できません: (1146、「テーブル 'legacy_db.django_content_type' が存在しません」)

テスト目的でレガシー データをフィクスチャに配置する必要があります。それを修正する方法はありますか？

私のdjangoプロジェクトでは、複数の主キーを持つテーブルを持つレガシーデータベースを使用しています。save()一部のモデル インスタンスでメソッドを呼び出すと、Django ORM が SQL クエリを正しく構築しないという問題に直面しています。

たとえば、次のモデルがあります。

そのようなモデルのインスタンスを取得します: mytable_instance = MyTable.objects.all()[0]. 次に、そのインスタンスを変更します。

ただし、Django ORM は次のクエリを実行します。

のすべての行に対して新しい値field_2を設定するため、これは正しくありませんfield_3my_tablefield_1 = 123

どうすればその問題を克服できますか? 次のような SQL クエリが必要です。

編集:完全なコード

従来のデータベース テーブルのモデル:

クエリ:

しかし、私は必要です：

私は、既存のレガシー ソフトウェアを書き直すプロジェクトに取り組んでいます。従来のソフトウェアは、主に SQL データベースに対する CRUD 操作 (作成、読み取り、更新、削除) で構成されています。

CRUD ベースのコーディング スタイルにもかかわらず、レガシー ソフトウェアは非常に複雑です。このソフトウェアの複雑さは、問題領域自体の複雑さの結果であるだけでなく、貧弱な (そして通常は非常識に近い) 設計上の決定の結果でもあります。この不十分なコーディングにより、データベース内のデータの整合性が失われています。これらの整合性の問題は、関係 (外部キー) だけでなく、単一の行内の整合性にも関係しています。たとえば、列「x」の意味は、列「y」の意味と完全に矛盾しています。(質問する前に、答えは「はい」です。私は問題のドメインを分析し、これらの列の意味と目的を正しく理解しており、元のソフトウェア開発者よりも優れているようです)。

代替ソフトウェアを作成するとき、主にドメインの複雑さのために、ドメイン駆動設計とコマンド クエリ責任分離の原則を使用しました。たとえば、書き込みモデルで不変条件を適用する集約ルート、「クロス集約」整合性チェックを実行するコマンド ハンドラー、さまざまな画面に適した方法で意図的に非正規化されたデータをクエリするクエリ ハンドラーなどを設計しました。

新しいデータを入力する場合、正確さと使いやすさの点で、代替ソフトウェアは非常にうまく機能します。その点では成功です。ただし、既存のデータには整合性の問題がたくさんあるため、既存のデータに関係する操作は、例外をスローして定期的に失敗します。これは通常、コンストラクターに渡されたデータが集計の不変条件に違反しているため、リポジトリから集計を読み取ることができないために発生します。

この「ルールを破る」レガシーデータをどのように処理すればよいでしょうか。古いソフトウェアは、ほとんど検証なしで実行されたため、この点で問題なく機能しました。この検証の欠如により、経験の浅いユーザーが無意味なデータを入力するのは簡単でした (また、経験豊富なユーザーは、その「特異性」を何年にもわたって理解しているため、非常に価値のあるものになりました)。

データ自体は非常に重要なため、破棄することはできません。私に何ができる？整合性の問題を整理してみましたが、これでうまくいく場合もあれば、ほぼ不可能な場合もあります (たとえば、元の開発者がデータを保存しないことにしたため、データがデータベースから完全に失われているなど)。データの整合性に関する問題の数は膨大です。

私に何ができる？

一部のテーブルに複合主キーが含まれている従来のデータベースがあります。コマンドを実行して取得したモデルはmanage.py inspectdb次のようになります。

正常にデータを取得できます。save()ただし、一部のモデル インスタンスでコマンドを実行したい場合に問題が発生します。django が実行するクエリは正しくありません。例えば：

しかし、私は必要です：

django は複合主キーをサポートしていないため、その問題を克服するための最良の解決策は何でしょうか? これは従来のデータベース テーブルであり、AutoField.

編集: 従来のテーブル構造を追加します

次のテーブルを持つ従来のデータベースがあります。

人

電話番号

すべての人は、0 個以上の電話番号を持つことができます。これは、person エンティティの多値属性です。

次のmodels.pyを生成したDjangoのinspectdbコマンドを使用してみました:

しかし、PhoneNumbers の新しいインスタンスを保存しようとすると、Django は次のエラー メッセージを返しました。

どうやら Django は、電話番号のテーブルに代理キーがあることを期待しています。電話番号のテーブルはエンティティではないため、従来のデータベースには代理キーがありません。phonenumbers テーブルの主キーは、そのすべての列の構成であることに注意してください。

これらのテーブルを Django のモデルにマップして、レガシー データベースで動作させるにはどうすればよいですか?

私たちのレガシー アプリケーションは当初、カスタマイズ可能なページの html タグを格納できるように設計されていました。このようなページのアイデアは、顧客が必要とする HTML を保存し、ある時点でこの HTML データをレンダリングする可能性があるということです。

このアプローチにより、ユーザーは任意の XSS を保存できました。現在の目標は、XSS の保存を許可しないポリシーを定義して適用することです。

いくつかの事前定義されたルールに基づいて、html をサニタイズできるいくつかのアプローチを検討しました。

• OWASP Java HTML サニタイザー
• スープ

しかし、どちらのアプローチも検証ではなくサニタゼーションに基づいています。したがって、基本的なシナリオは次のようになります。

1. ユーザーが入力するデータを入力します
2. ユーザー入力はサニタイズされ、生の (初期 - ステップ 1) ユーザー入力と等しいかどうかがチェックされます。
3. 検証が失敗したと見なされる違いがある場合。

このアプローチは、新しいデータに対して機能します。レガシー データの場合、いくつかの問題が発生します。

1. ユーザーのレガシー データに禁止された要素が含まれている場合、ユーザーは HTML コンテンツのわずかに変更されたバージョンを保存できません。
2. 次のフローはユーザーを混乱させます。
   1. ユーザーは、新しく定義されたポリシーに関する禁止タグ/コンテンツを含むレガシー データを編集します。
   2. ユーザーはすべてのコンテンツを置き換えて保存します。
   3. ユーザーが何らかの理由で古いバージョンに戻すことを決定した
   4. 禁止されたタグ/コンテンツが含まれているため、ユーザーは以前のバージョンを保存できません。

したがって、次の質問が表示されます。

1. 悪意のある html 要素と XSS ベクターのユーザー入力を検証する最善の方法は何ですか?
2. レガシ データに関する前述の問題を解決するには、どのアプローチを使用できますか?

次の SQL クエリを使用して作成されたデータベース テーブルがあるとします。

Django ORM で使用する必要があるため、inspectdbコマンドを実行しました。それは自動生成されたコードです:

アプリのmodels.pyファイルに保存して移行を実行すると、すべて問題ありませんでした。ORM を使用して作成されたように、DB を読み取ることができました。ただし、Bill テーブルの行の作成に問題がありました。

Bill モデルの単純な形式です。

問題は、DB シーケンスで生成された ID を取得できないことです。コードでフィールドを生成してから引数として渡す必要があるため、フォームにフィールドを追加するidことはできません。データベースよりも、生のクエリなしでは取得できない別の ID が作成されます。