Detaillierte Erläuterung der Schritte zur Verwendung mehrerer Django-Datenbanken

Dieses Mal werde ich Ihnen die Schritte zur Verwendung mehrerer Django-Datenbanken ausführlich erläutern. Was sind die Vorsichtsmaßnahmen für die Verwendung mehrerer Django-Datenbanken?

1. Stellen Sie DATABASE in den Einstellungen ein

Wenn Sie beispielsweise zwei Datenbanken verwenden möchten:

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

Auf diese Weise werden zwei Datenbanken identifiziert, eine mit dem Alias-Standard und die andere mit dem Alias-Benutzer. Der Datenbank-Alias ​​kann beliebig bestimmt werden.

Der Alias ​​„Default“ ist etwas Besonderes. Wenn in der Route kein Modell speziell ausgewählt ist, wird standardmäßig die Standarddatenbank verwendet.

Natürlich kann der Standardwert auch auf leer gesetzt werden:

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

Da es keine Standarddatenbank gibt, muss auf diese Weise das Datenbankrouting für alle Modelle durchgeführt werden, einschließlich der Modelle in verwendeten Bibliotheken von Drittanbietern.

2. Geben Sie app_label

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

für das Modell an, das eine Datenbankauswahl treffen muss 3. Datenbankrouter schreiben

Database Router wird verwendet, um zu bestimmen, welche Datenbank ein Modell verwendet. Er definiert hauptsächlich die folgenden vier Methoden:

db_for_read(model, **hints)

Geben Sie an, welche Datenbank zum Lesen des Modells verwendet werden soll.

db_for_write(model, **hints)

Geben Sie an, welche Datenbank zum Schreiben des Modells verwendet werden soll.

allow_relation(obj1, obj2, **hints)

Bestimmen Sie, ob obj1 und obj2 verknüpft werden können. Dies wird hauptsächlich für Fremdschlüssel und viele zu viele Operationen verwendet.

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

Bestimmen Sie, ob der Migrationsvorgang auf dem Datenbankalias db ausgeführt werden kann.

Ein vollständiges Beispiel:

Datenbankeinstellungen:

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

Wenn Sie folgende Effekte erzielen möchten:

Das Lesen und Schreiben des Modells, dessen app_label auth ist, wird in auth_db abgeschlossen, der Rest des Modellschreibens wird in der Primärdatenbank abgeschlossen und das Lesen wird zufällig in Replikat1 und Replikat2 abgeschlossen.

Authentifizierung:

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

Auf diese Weise wird das Lesen und Schreiben des Modells, dessen app_label auth ist, in auth_db abgeschlossen, und die Zuordnung kann nur in der auth_db-Datenbank ausgeführt werden.

Der 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

Auf diese Weise wird das Lesen zufällig in Replikat1 und Replikat2 abgeschlossen, und das Schreiben wird primär verwendet.

Stellen Sie es schließlich in den Einstellungen ein:

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

Das ist es.

Beim Durchführen eines Migrationsvorgangs:

$ ./manage.py migrate
$ ./manage.py migrate --database=users

Der Migrationsvorgang wird standardmäßig auf der Standarddatenbank ausgeführt. Um andere Datenbanken zu bearbeiten, können Sie die Option --database verwenden, gefolgt vom Alias ​​der Datenbank.

Dementsprechend verfügen die Befehle dbshell, dumpdata und loaddata alle über die Option --database.

Sie können die Route auch manuell auswählen:

Abfrage:

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

Speichern:

>>> my_object.save(using='legacy_users')

Umzug:

>>> p = Person(name='Fred')
>>> p.save(using='first') # (statement 1)
>>> p.save(using='second') # (statement 2)

Der obige Code verursacht Probleme, wenn p zum ersten Mal in der ersten Datenbank gespeichert wird. Auf diese Weise verfügt p bereits über einen Primärschlüssel, wenn er zum Speichern die zweite Datenbank verwendet Der Schlüssel verursacht keine Probleme, wenn er nicht verwendet wird. Wenn er jedoch zuvor verwendet wurde, werden die Originaldaten überschrieben.

Es gibt zwei Lösungen:

1. Löschen Sie den Primärschlüssel vor dem Speichern:

>>> 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. Verwenden Sie force_insert

>>> p = Person(name='Fred')
>>> p.save(using='first')
>>> p.save(using='second', force_insert=True)

Löschen:

Aus welcher Datenbank wurde das -Objekt bezogen und wo wurde das

>>> u = User.objects.using('legacy_users').get(username='fred')
>>> u.delete() # will delete from the `legacy_users` database

gelöscht? Wenn Sie ein Objekt aus der Datenbank „legacy_users“ in die Datenbank „new_users“ übertragen möchten:

>>> user_obj.save(using='new_users')
>>> user_obj.delete(using='legacy_users')

Ich glaube, dass Sie die Methode beherrschen, nachdem Sie den Fall in diesem Artikel gelesen haben. Weitere spannende Informationen finden Sie hier Verwandte Artikel auf der chinesischen PHP-Website!

Empfohlene Lektüre:

So verwenden Sie Babel in WebStorm ES6

Verwenden Sie React, um Komponenten in bestimmten DOM-Knoten zu rendern

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung der Schritte zur Verwendung mehrerer Django-Datenbanken. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!