5

私はDjango Frameworkの下でウェブサイトを構築していますが、このWebサイトは異なるSQLスキームを持つ必要があります。今はすべてのスキームとすべてのものを作成することに成功しましたが、なぜdjango_migrationsデータベースの移行後に各スキーマに存在します。なぜすべてのデータベースのdjango_migrationsテーブル

  • 予想されるデータベースの内容:

    AppDBテーブル

    デフォルトDBテーブルは、すべてのDjangoのテーブルです。このアプリで定義されたすべてのモデル(管理者、contenttypesの、認証、セッション)

    です
  • データベース内容:

    AppDBテーブルは、すべてのDjangoのテーブル(管理者、contenttypesの、認証、セッション)+ django_migrations

これら

は、ルータのがされているすべてのこのアプリで定義されたモデル+ django_migrations

DEFAULTテーブルです2 dbs:

class DefaultRouter(object): 
    APPS = ['auth', 'sessions', 'admin', 'contenttypes'] 
    DB = 'default' 

    def db_for_read(self, model, **hints): 
     if model._meta.app_label in self.APPS: 
      return self.DB 
     return None 

    def db_for_write(self, model, **hints): 

     if model._meta.app_label in self.APPS: 
      return self.DB 

     return None 

    def allow_relation(self, obj1, obj2, **hints): 

     if obj1._meta.app_label in self.APPS or obj2._meta.app_label in self.APPS: 
      return True 
     return None 

    def allow_migrate(self, db, app_label, model_name=None, **hints): 

     if app_label in self.APPS: 
      return db == self.DB 
     return None 


class MyAppDBRouter(object): 
    def db_for_read(self, model, **hints): 
     return self.check_app_label(model) 

    def db_for_write(self, model, **hints): 
     return self.check_app_label(model) 

    def allow_relation(self, obj1, obj2, **hints): 
     if obj1._meta.app_label == 'myapp' or obj2._meta.app_label == 'myapp': 
      return True 
     return None 

    def allow_migrate(self, db, app_label, model_name=None, **hints): 
     if app_label == 'myapp': 
      return db == 'appdb' 
     return None 

    @staticmethod 
    def check_app_label(model): 
     if model._meta.app_label == 'myapp': 
      return 'appdb' 
     return None 

ありがとうございます。

答えて

0

django_migrationsそのデータベースに移行が適用されているテーブルレコード。これは、Djangoの移行システムがデータベースの現在の状態と移行を実行する必要があることを理解するためのメカニズムです。したがって、すべてのデータベースで必要です。

ここで、マイグレーションが実際には必要ないテーブル(たとえば、読み取り専用データベース)があると、問題が発生する可能性があります。それはthis ticketの件です。

+0

あなたは私が尋ねたことを理解していないと思う、私の質問はこれです 私は2 dbを持って、1つはdjangoの情報を含める必要があり、もう1つは私のアプリケーションのデータのみを含める必要があります。 プロジェクトを移行すると、同じデータを持つ両方のdbにdjango_migrationsテーブルが作成されますが、これを避けるためにほとんどすべてを試しましたが、何も役に立ちませんでした。 –

+0

@NadirAlbajari:不可能です。あなたが言及した他のテーブルは単なるオプションのアプリであり、どこにでも置くことができます。移行テーブルはオプションではなく、各データベースに存在していなければならないため、そのデータベースに適用されている移行を追跡できます。 –

+0

ありがとう@ケビン、私はこれを理解しますが、私は2つのアプリケーション(app1、app2)と2つのデータベース(db1、db2)を持っていると仮定して、db1のapp1とdb2のapp2と同じ関連マイグレーションをしたいと思います。 db1の移行テーブルには2つのアプリケーションの移行とdb2の移行が含まれています。 これはなぜ起こっているのでしょうか?2つのアプリを分離して移行する方法はありますか? もう一度ありがとう! –

0

バージョン1.7より前のDjangoでは、django_migrationsテーブルはありませんでした。その後、Djangoにはデータベーススキーマに関連する変更、つまりフィールド定義の変更、db.models内のフィールドの追加または削除を処理するための移行が正しく含まれていました。

は、以前のバージョンでは、開発者は、まさにこれを行うためにdjango_south_migrationアプリを使用しますが、ほとんど誰もがそれを使用していたことから、Djangoは以降の1.7バージョンに含まれています。

django_migrationsテーブルは、データベースに適用されたデータベーススキーマの変更の記録を保持します。この表は、djangoが python manage.py makemigrationsの後に作成された新しい移行を適用するのに役立ちます。

この表のapp列この移行が適用されたアプリの名前を記録します。任意のdjangoアプリケーションのマイグレーションディレクトリに移動すると、0001_auto .pyなどのマイグレーションファイルが表示されます。
たとえば、この移行がデータベースに適用されている場合、name = 0001_autoおよびapp = django_migrationsテーブルにあります。

+0

私はあなたが私が尋ねたことを理解していないと思う、私の質問はこれです 私は2 DBを持って、1つはdjangoの情報を含める必要があり、もう1つは私のアプリのデータのみを含める必要があります。 プロジェクトを移行すると、両方のdbに同じデータのdjango_migrationsテーブルが作成されますが、これを避けるためにほとんどすべてを試しましたが、何も助けませんでした –

関連する問題