Home  >  Article  >  Web Front-end  >  Introduction to how Django uses multiple database methods

Introduction to how Django uses multiple database methods

巴扎黑
巴扎黑Original
2017-09-07 10:17:081507browse

Some projects may involve the use of multiple databases, and the method is very simple. Next, this article will introduce you to the method of using multiple databases in Django. Friends who need it can refer to it

Some projects may involve the use of multiple databases. The method is very simple.

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'
  }
}

This way Two databases have been 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, you need to set the default database for all Models, including the ones used. The Model in the third-party library performs database routing selection.

2. Specify app_label for the Model that needs to make database selection


class MyUser(models.Model):
  ...
  class Meta:
    app_label = 'users'

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)

Specifies which database the model uses A database read.

db_for_write(model, **hints)

Specifies which database to use for model writing.

allow_relation(obj1, obj2, **hints)

Determine whether obj1 and obj2 can be related, mainly used for foreign key and many to many operations.

allow_migrate(db, app_label, model_name=None, **hints)

Determines whether the migrate operation can be run on the database with the 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, and associations are allowed. Migrate can only 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 done randomly in replica1 and replica2, and writing uses primary.

Finally set it in settings:


DATABASE_ROUTERS = ['path.to.AuthRouter', 'path.to.PrimaryReplicaRouter']

.

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. What follows is the alias of the database.

Correspondingly, the dbshell, dumpdata, and loaddata commands all have the --database option.

You can also select the route manually:

Query:

##

>>> # 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')

Move:

>>> 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 for the first time in the first database, a primary key will be generated by default, so use it When the second database is saved, 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:

Which database the object is obtained from and where to delete it

>>> 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')

The above is the detailed content of Introduction to how Django uses multiple database methods. For more information, please follow other related articles on the PHP Chinese website!

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn