Changes between Version 16 and Version 17 of MultipleDatabaseSupport


Ignore:
Timestamp:
Sep 10, 2008, 7:59:35 PM (16 years ago)
Author:
simon
Comment:

this page is a bit more relevant now

Legend:

Unmodified
Added
Removed
Modified

  • MultipleDatabaseSupport

    v16 v17  
    11= Multiple Database Support =
    22
    3 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.
     3''See PreviousMultipleDatabaseBranch for information on a previous attempt at adding this.''
    44
    5 == Current status ==
    6 
    7 '''FEATURE COMPLETE''' (alpha)
    8 
    9 All features are implemented and all tests pass. Much work remains in documenting the new features and extending test coverage.
    10 
    11 Work is ongoing in the multiple-db-support branch, which you can check out thusly:
    12 
    13 {{{
    14 svn co http://code.djangoproject.com/svn/django/branches/multiple-db-support
    15 }}}
    16 
    17 or view in the source browser at: source:/django/branches/multiple-db-support
    18 
    19 Most of the basic implementation is done, with the exception of the items in this todo list:
    20 
    21 ||'''TODO'''||'''status'''||
    22 ||Fix django.core.management.syncdb. syncdb is not implemented correctly using new features.||DONE||
    23 ||Merge to trunk [3661]. This trunk changeset moves a number of test features and removes the othertests directory, and will need a lot of hand-merging||DONE in [3712]||
    24 ||OTHER_DATABASES not DATABASES||DONE||
    25 ||MODELS entry in OTHER_DATABASES not model._meta.db_connection||DONE||
    26 ||Move connection info to manager||DONE||
    27 ||Tests for thread/request isolation||DONE||
    28 ||Generate sql for dropping tables in django.db.backends.sql.ansi||DONE||
    29 ||Generate sql for resetting sequences in postgres backend SchemaBuilder subclass||DONE||
    30 ||When validating models, warn user if a model references another model that is configured to use a different connection||DONE||
    31 ||Create mutliple_db.txt doc documenting use of settings, transactions, etc.||||
    32 ||Link to multiple db doc from other docs where appropriate||||
    33 ||Review tests and extend where appropriate||||
    34 
    35 == The plan ==
    36 
    37  * 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.
    38 
    39  * Add a new settings variable, OTHER_DATABASES. OTHER_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. Each set of settings may also define a list of models that will use that connection by default. Each item in the MODELS list may an app label (in which case it applies to all models with that app label) or app_label.Model, in which case it applies only to that specific model.
    40 
    41 {{{
    42 #!python
    43 OTHER_DATABASES = {
    44     'a': { 'DATABASE_ENGINE': 'sqlite3',
    45            'DATABASE_NAME': '/tmp/dba.db'
    46            'MODELS': ['app_label', 'app_label_2.Model']
    47     },
    48     'b': { 'DATABASE_ENGINE': 'sqlite3',
    49            'DATABASE_NAME': '/tmp/dbb.db'
    50     }}
    51 }}}   
    52 
    53  
    54 
    55  * Add db attribute to Managers. This allows access to the connection that a model should use, as determined by settings. It may also be changed on the fly to use a different connection for a particular query or set of queries. When assigning to Manager.db, assign a django.db.ConnectionInfo; the easiest way to get one is from the django.db.connections dict.
    56 
    57 {{{
    58 #!python
    59 class Artist(models.Model):
    60     name = models.CharField(maxlength=100)
    61     alive = models.BooleanField(default=True)
    62 
    63     def __str__(self):
    64         return self.name'
    65        
    66 class Widget(models.Model):
    67     code = models.CharField(maxlength=10, unique=True)
    68     weight = models.IntegerField()
    69 
    70     def __str__(self):
    71         return self.code
    72  
    73 settings.OTHER_DATABASES['a']['MODELS'] = ['Artist']
    74 settings.OTHER_DATABASES['b']['MODELS'] = ['Widget']
    75 
    76 # get the db connection
    77 connection = Artist.objects.db.connection
    78 
    79 # assign another connection
    80 Widget.objects.db = connections['other_widget_connection']
    81 
    82 }}}
    83 
    84  * Allow transaction decorators, etc to take optional connections argument. Without that argument, transactions will apply across all connections already in use.
    85  
    86  * Move generation of schema manipulating sql (CREATE TABLE, etc) from django.core.management into django.db.backends.ansi.sql. Schema statements are build with a SchemaBuilder instance; each backend gets an instance in its creation module as creation.builder.
    87 
    88  * 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.
    89 
     5A more recent discussion about multi-db support can be seen on this thread: http://groups.google.com/group/django-developers/browse_thread/thread/9f0353fe0682b73
Back to Top