Home > Article > Web Front-end > Detailed explanation of the steps to use Django multiple databases
This time I will bring you a detailed explanation of the steps for using Django multi-database. What are the precautions for using Django multi-database. The following is a practical case, let's take a look.
1. Set DATABASE
in settings For example, if you want to use two databases:
DATABASES = {
'default': {
'NAME': 'app_data',
'ENGINE': 'django.db.backends.postgresql',
'USER': 'postgres_user',
'PASSWORD': 's3krit'
},
'users': {
'NAME': 'user_data',
'ENGINE': 'django.db.backends.mysql',
'USER': 'mysql_user',
'PASSWORD': 'priv4te'
}
}
In this way, two databases are identified, one with the alias default and the other with the alias user. The database alias can be determined arbitrarily.
The alias of default is special. When a Model is not specifically selected in the route, the default database is used by default.
Of course, default can also be set to empty:
DATABASES = {
'default': {},
'users': {
'NAME': 'user_data',
'ENGINE': 'django.db.backends.mysql',
'USER': 'mysql_user',
'PASSWORD': 'superS3cret'
},
'customers': {
'NAME': 'customer_data',
'ENGINE': 'django.db.backends.mysql',
'USER': 'mysql_cust',
'PASSWORD': 'veryPriv@ate'
}
}
In this way, because there is no default database, database routing needs to be done for all Models, including Models in third-party libraries used.
2. Specify app_label
class MyUser(models.Model): ... class Meta: app_label = 'users'
for the Model that needs to make database selections 3. Write Database Routers
Database Router is used to determine which database a Model uses. It mainly defines the following four methods:
db_for_read(model, **hints)
Specify which database to use for model reading.
db_for_write(model, **hints)
Specify which database to use for writing the model.
allow_relation(obj1, obj2, **hints)
Determine whether obj1 and obj2 can be associated, mainly used for foreign key and many to many operations.
allow_migrate(db, app_label, model_name=None, **hints)
Determine whether the migrate operation can be run on the database alias db.
A complete example:
Database settings:
DATABASES = {
'default': {},
'auth_db': {
'NAME': 'auth_db',
'ENGINE': 'django.db.backends.mysql',
'USER': 'mysql_user',
'PASSWORD': 'swordfish',
},
'primary': {
'NAME': 'primary',
'ENGINE': 'django.db.backends.mysql',
'USER': 'mysql_user',
'PASSWORD': 'spam',
},
'replica1': {
'NAME': 'replica1',
'ENGINE': 'django.db.backends.mysql',
'USER': 'mysql_user',
'PASSWORD': 'eggs',
},
'replica2': {
'NAME': 'replica2',
'ENGINE': 'django.db.backends.mysql',
'USER': 'mysql_user',
'PASSWORD': 'bacon',
},
}
If you want to achieve the following effects:
The reading and writing of the Model whose app_label is auth are completed in auth_db, the rest of the Model writing is completed in the primary, and the reading is completed randomly in replica1 and replica2.
auth:
class AuthRouter(object): """ A router to control all database operations on models in the auth application. """ def db_for_read(self, model, **hints): """ Attempts to read auth models go to auth_db. """ if model._meta.app_label == 'auth': return 'auth_db' return None def db_for_write(self, model, **hints): """ Attempts to write auth models go to auth_db. """ if model._meta.app_label == 'auth': return 'auth_db' return None def allow_relation(self, obj1, obj2, **hints): """ Allow relations if a model in the auth app is involved. """ if obj1._meta.app_label == 'auth' or \ obj2._meta.app_label == 'auth': return True return None def allow_migrate(self, db, app_label, model_name=None, **hints): """ Make sure the auth app only appears in the 'auth_db' database. """ if app_label == 'auth': return db == 'auth_db' return None
In this way, the reading and writing of the Model whose app_label is auth are completed in auth_db, allowing association, and migrate can only be run in the auth_db database.
The rest:
import random
class PrimaryReplicaRouter(object):
def db_for_read(self, model, **hints):
"""
Reads go to a randomly-chosen replica.
"""
return random.choice(['replica1', 'replica2'])
def db_for_write(self, model, **hints):
"""
Writes always go to primary.
"""
return 'primary'
def allow_relation(self, obj1, obj2, **hints):
"""
Relations between objects are allowed if both objects are
in the primary/replica pool.
"""
db_list = ('primary', 'replica1', 'replica2')
if obj1._state.db in db_list and obj2._state.db in db_list:
return True
return None
def allow_migrate(self, db, app_label, model_name=None, **hints):
"""
All non-auth models end up in this pool.
"""
return True
In this way, reading is completed randomly in replica1 and replica2, and writing uses primary.
Finally set it in settings:
DATABASE_ROUTERS = ['path.to.AuthRouter', 'path.to.PrimaryReplicaRouter']
That's it.
When performing a migrate operation:
$ ./manage.py migrate $ ./manage.py migrate --database=users
The migrate operation operates on the default database by default. To operate on other databases, you can use the --database option, followed by the alias of the database.
Correspondingly, the dbshell, dumpdata, and loaddata commands all have the --database option.
You can also select the route manually:
>>> # This will run on the 'default' database.
>>> Author.objects.all()
>>> # So will this.
>>> Author.objects.using('default').all()
>>> # This will run on the 'other' database.
>>> Author.objects.using('other').all()
Save:
>>> my_object.save(using='legacy_users')
Mobile:
>>> p = Person(name='Fred') >>> p.save(using='first') # (statement 1) >>> p.save(using='second') # (statement 2)
The above code will cause problems. When p is saved in the first database for the first time, a primary key will be generated by default. When saving in the second database, p already has a primary key. This primary key will not cause problems if it is not used, but If it has been used previously, the original data will be overwritten.
There are two solutions;
1. Clear the primary key before saving:
>>> p = Person(name='Fred') >>> p.save(using='first') >>> p.pk = None # Clear the primary key. >>> p.save(using='second') # Write a completely new object.
2. Use force_insert
>>> p = Person(name='Fred') >>> p.save(using='first') >>> p.save(using='second', force_insert=True)
delete:
From which database the object was obtained and where was it deleted
>>> u = User.objects.using('legacy_users').get(username='fred')
>>> u.delete() # will delete from the `legacy_users` database
If you want to transfer an object from the legacy_users database to the new_users database:
>>> user_obj.save(using='new_users') >>> user_obj.delete(using='legacy_users')
I believe you have mastered the method after reading the case in this article. For more exciting information, please pay attention to other related articles on the PHP Chinese website!
Recommended reading:
How to use babel in WebStorm ES6
##Use React to render components to specified DOM nodes
The above is the detailed content of Detailed explanation of the steps to use Django multiple databases. For more information, please follow other related articles on the PHP Chinese website!