Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why is django_migrations table in all databases

I'm building a website under Django Framework, this website needs to have different SQL schemes, for now I succeeded creating all schemes and all stuff, but I don't understand why the table django_migrations is in each schema after migration of databases.

  • Expected Databases Content:

    AppDB tables are all the models defined by this app

    Default DB tables are all Django tables (admin, contenttypes, auth, sessions)

  • Databases Content:

    AppDB tables are all the models defined by this app + django_migrations

    DEFAULT tables are all Django tables (admin, contenttypes, auth, sessions) + django_migrations

Those are the routers of the 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

Thanks.

like image 855
Nadir Albajari Avatar asked Apr 27 '16 16:04

Nadir Albajari


People also ask

What is database migration in Django?

Django Database Migrations. Migration is a way of applying changes that we have made to a model, into the database schema. Django creates a migration file inside the migration folder for each model to create the table schema, and each table is mapped to the model of which migration is created.

Why does the migrations table exist on each database?

The migrations table is not optional, it must exist on each database so it can track which migrations have been applied on that database.

Why does Django need to know the current state of database?

It's the mechanism by which the Django migration system understands the current state of the database and which migrations need to be run. So it's required on all the databases. Now, if you had a table that didn't actually need migrations—say, a read-only database—then this could cause problems. That's the subject of this ticket.

Is Django migration backwards compatible with Django X?

The migrations system will maintain backwards-compatibility according to the same policy as the rest of Django, so migration files generated on Django X.Y should run unchanged on Django X.Y+1. The migrations system does not promise forwards-compatibility, however.


2 Answers

The django_migrations table records which migrations have been applied on that database. It's the mechanism by which the Django migration system understands the current state of the database and which migrations need to be run. So it's required on all the databases.

Now, if you had a table that didn't actually need migrations—say, a read-only database—then this could cause problems. That's the subject of this ticket.

like image 92
Kevin Christopher Henry Avatar answered Sep 21 '22 00:09

Kevin Christopher Henry


Prior to Version 1.7 of Django, there was no django_migrations table. Thereafter, Django rightly included migrations for handling database schema related changes, that is changes in field definition, addition or deletion of fields in db.models.

In Earlier versions, developers use django_south_migration app for doing exactly this but since almost everybody was using it, Django included in 1.7 version onwards.

Now coming to your question, django_migrations table keep records of changes in database schema applied to database. This table helps django in applying new migrations created after python manage.py makemigrations.

app column of this table records name of the app to which this migration was applied. If you will go to migrations directory of any django app, you will see migration files of the form 0001_auto.py etc.
eg if this migration has been applied to database, you will find an entry with name=0001_auto and app= in django_migrations table.

like image 25
Amit Jaiswal Avatar answered Sep 21 '22 00:09

Amit Jaiswal