2016-12-13 13 views
0

に格納されている外部キー参照は、モデルからの移行を実行してDjangoのレベルまたはのMySQLdb

CREATE TABLE `table2` (
    `id` int(11) NOT NULL DEFAULT '0', 
    `table1_id` int(11) NOT NULL 
) ENGINE=InnoDB DEFAULT CHARSET=latin1 

として定義

CREATE TABLE `table1` (
    `id` int(11) NOT NULL DEFAULT '0' 
) ENGINE=InnoDB DEFAULT CHARSET=latin1 

table2として作成MySQLのテーブルが存在することを検討しています。

ここで、表2は1を参照しており、この関係はモデルに記載されています。今、私がこれらのテーブルをMySQLでクエリすると、table2から1への参照のようなものは表示されません。

私はこのような関係を保存するのは、djangoの責任であることを知りたいと思います。もしそうなら、私はORMをdjangoから何かに変更しなければならない場合、どのようにしてそのような関係を移行することができますか?

また、「ORMは、そのような関係を確実にするためのラッパーです」と考えると、移行を介してテーブルを作成するときにそのような関係を作成しないでください。これは、参照がテーブル定義の一部になることを保証することを意味します。だから明日私が別のORMを使うことを選んだのであれば、テーブル定義をインポートするだけです。

私が間違っている場合は、私に修正してください。

+0

djangoのように見えるのは、そのような関係がテーブル定義の一部であることを保証しているようです。私は間違った場所を見ていた。皆さんありがとう。 – techsavvy

答えて

1

ORMは、データベース、そのスキーマおよびそのデータを取得するための単なる上位レベルの方法です。それは何も格納しません、それはちょうどスキーマで定義されているように、以下のデータで作業する方法を提供します。

ここで示したスキーマでは、table2にtable1_idが含まれています。

migrationsのドキュメントで非常に最初の行:

の移行は(、フィールドを追加したモデルなどを削除)、あなたのモデルに加えた変更を伝播するデータベース・スキーマにのDjangoの方法です。

しかし、その最後には、Djangoとまったく関係のないデータベーススキーマが残っています。

+0

ORMがそのような関係を確実に守るためのラッパーであるという事実に同意すれば、マイグレーションによるテーブルの作成中にそのような関係を作成しないのはなぜですか。 – techsavvy

+0

@techsavvy - dbスキーマに 'table1_id'フィールドを作成するのが好きですか? – Sayse

+0

こんにちは@この質問に答えるために感謝します。私は質問を更新しました。これらの表は、モデル内でマイグレーションを実行することによって作成されます。 – techsavvy

0

どのように関係すると思われますか? Table1_idは、他のテーブルへの参照に似ています。

どのようにtable1_idを入力する必要がありますか?すべてが手動入力の場合、問題はありません。

関連する問題