2016-07-11 1 views
2

CharFieldsとForeignKeyがほんの少ししかないDjangoモデル(Python 3.5/Django 1.9.7/SQLiteを使用)を作成した後、manage.py makemigrationsを実行して、作成したSQLコードをmanage.py sqlmigrate APP_NAME, MIGRATION_NAMEで分析しました。Django makemigrationsがモデルを作成する理由をmodel_oldに変更し、再度作成してmodel_oldを削除しますか?

誰かが、なぜmodel_oldにテーブルの名前を変更し、再び作成し、作成した/名前を変更したmodel_oldから作成したテーブルにデータをインポートしてから、model_oldテーブルを削除するのか説明できますか?

私は実際に必要なテーブルで正しい結果が得られることを知り、なぜそれがそれをしているのか理解しようとしています。ベローは、ここで生成されたSQLスクリプト

BEGIN; 
-- 
-- Create model Foo 
-- 
CREATE TABLE "foo_foos" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "created" datetime NOT NULL, "modified" datetime NOT NULL, "name" varchar(250) NOT NULL, "description" varchar(250) NOT NULL,"bar_id" integer NULL REFERENCES "foo_bar" ("id")); 
-- 
-- Alter unique_together for foos (1 constraint(s)) 
-- 
ALTER TABLE "foo_foos" RENAME TO "foo_foos__old"; 
CREATE TABLE "foo_foos" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "created" datetime NOT NULL, "modified" datetime NOT NULL, "name" varchar(250) NOT NULL, "description" varchar(250) NOT NULL,"bar_id" integer NULL REFERENCES "foo_bar" ("id"));; 
INSERT INTO "foo_foos" ("created", "modified", "name", "description", "id", "bar_id") SELECT "created", "modified", "name", "description", "id", "bar_id" FROM "foo_foos__old"; 
DROP TABLE "foo_foos__old"; 
CREATE UNIQUE INDEX "foo_foos_name_42a88411_uniq" ON "foo_foos" ("name", "description"); 
CREATE INDEX "foo_foos_3b5ba656" ON "foo_foos" ("foo_id"); 

COMMIT; 

とは次のようにモデルがどのように見えるかです:それはDjangoの公式ドキュメントから取られ、SQLiteののDjangoのエミュレーションについてのすべてです

class Foo(models.Model): 
    name = models.CharField(max_lenght=250) 
    description = models.CharField(max_lenght=250) 
    bar = models.ForeignKey(Bar, on_delete=models.SET_NULL) 

    class Meta: 
     unique_together = ('name', 'description') 

答えて

0

ここでの説明です:

SQLite¶

SQLiteにはスキーマの変更が組み込まれているため、Djangoはこれをエミュレートします:

Creating a new table with the new schema 
Copying the data across 
Dropping the old table 
Renaming the new table to match the original name 

このプロセスは一般的にはうまくいきますが、処理が遅く、時折バグが発生することがあります。リスクとその限界を十分に理解していない限り、本番環境でSQLiteを実行して移行することはお勧めしません。 Djangoが提供するサポートは、開発者がローカルマシンでSQLiteを使用して完全なデータベースを必要とせずに複雑さの低いDjangoプロジェクトを開発できるように設計されています

関連する問題