Version 3 (modified by jpellerin@…, 9 years ago) (diff)

Add current status

Multiple Database Support

Work is underway on a patch for #1142, which will add support for multiple database connections. This page documents my current plan and progress towards a fully working patch.

The plan

  • Avoid any change that impacts backward compatibility. The intent is to add new functionality for those who need it, not to change the most common use case of a single database connection.
  • Add a new settings variable, DATABASES. DATABASES is a dict of named database connection parameter sets. In each set, the keys are the same as the standard database connection settings variables.
    DATABASES = { 
        'a': { 'DATABASE_ENGINE': 'sqlite3',
               'DATABASE_NAME': '/tmp/dba.db'
        },
        'b': { 'DATABASE_ENGINE': 'sqlite3',
               'DATABASE_NAME': '/tmp/dbb.db'
        }}
    

  • Add db_connection to Meta. This allows model classes to specify which connection they should use.
    class Artist(models.Model):
        name = models.CharField(maxlength=100)
        alive = models.BooleanField(default=True)
    
        def __str__(self):
            return self.name
    
        class Meta:
            db_connection = 'a'
            
    class Widget(models.Model):
        code = models.CharField(maxlength=10, unique=True)
        weight = models.IntegerField()
    
        def __str__(self):
            return self.code
        
        class Meta:
            db_connection = 'b'
    
  • Allow transaction decorators, etc to take optional connections argument. Without that argument, transactions will apply across all connections already in use. The default connection is always included.

  • Move generation of schema manipulating sql (CREATE TABLE, etc) from django.core.management into backend.creation.
  • Add methods to Manager to support per-model installation. This will enable each model to be installed using the connection that it specifies. It causes some complications, mainly in determining the correct order in which to install. My current solution is to depend on the developer already having figure that out by defining her models in a sensible order; and, when that fails, punting any unresolved constraints to the end of the syncdb or install process. The manager methods will delegate to each model's backend to do the sql creation.

Current status

Current patch is attached. It implements most of the model-level changes, a few manager-level changes, and table creation for postgres and sqlite. It does not implement any transaction changes, and nothing has been removed yet from django.core.management; the model table cration code there has just been adapted in django.db.backends.ansi.creation.

Attachments (6)

Download all attachments as: .zip

Back to Top