Changes between Version 8 and Version 9 of MultipleDatabaseSupport


Ignore:
Timestamp:
Jul 19, 2006, 1:19:57 PM (18 years ago)
Author:
jpellerin
Comment:

Updated current status, description of changes, and examples

Legend:

Unmodified
Added
Removed
Modified

  • MultipleDatabaseSupport

    v8 v9  
    55=== Current status ===
    66
    7 '''HIGHLY UNSTABLE''' The branch is in the middle of major implementation changes, some of which are waiting to merge refactoring from trunk. It will be unstable and unusable for at least a few days.
     7'''USEABLE'''
    88
    9 Several aspects of the design outlined below have changed, after discusson on the developer's list. I'm hoping to be able to update the code and this page within the next few days.
     9All tests pass. Much work remains in integrating changes into django.core.management and improving docs and tests.
    1010 
    1111Work is ongoing in the multiple-db-support branch, which you can check out thusly:
    … …  
    1818
    1919||'''TODO'''||'''status'''||
    20 ||OTHER_DATABASES not DATABASES||||
    21 ||MODELS entry in OTHER_DATABASES not model._meta.db_connection||||
    22 ||Move connection info to manager||||
     20||OTHER_DATABASES not DATABASES||DONE||
     21||MODELS entry in OTHER_DATABASES not model._meta.db_connection||DONE||
     22||Move connection info to manager||DONE||
    2323||Tests for thread/request isolation||||
    24 ||Generate sql for dropping tables in django.db.backends.sql.ansi||||
     24||Generate sql for dropping tables in django.db.backends.sql.ansi||DONE||
    2525||Generate sql for resetting sequences in postgres backend SchemaBuilder subclass||||
    2626||When validating models, warn user if a model references another model that is configure to use a different connection||||
    … …  
    3333 * 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.
    3434
    35  * 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.
     35 * 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.
     36
    3637{{{
    3738#!python
    38 DATABASES = {
     39OTHER_DATABASES = {
    3940    'a': { 'DATABASE_ENGINE': 'sqlite3',
    4041           'DATABASE_NAME': '/tmp/dba.db'
     42           'MODELS': ['app_label', 'app_label_2.Model']
    4143    },
    4244    'b': { 'DATABASE_ENGINE': 'sqlite3',
    … …  
    4749 
    4850
    49  * Add db_connection to Meta. This allows model classes to specify which connection they should use.
     51 * 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.
     52
    5053{{{
    5154#!python
    … …  
    5558
    5659    def __str__(self):
    57         return self.name
    58 
    59     class Meta:
    60         db_connection = 'a'
     60        return self.name'
    6161       
    6262class Widget(models.Model):
    … …  
    6666    def __str__(self):
    6767        return self.code
    68    
    69     class Meta:
    70         db_connection = 'b'
     68 
     69settings.OTHER_DATABASES['a']['MODELS'] = ['Artist']
     70settings.OTHER_DATABASES['b']['MODELS'] = ['Widget']
     71
     72# get the db connection
     73connection = Artist.objects.db.connection
     74
     75# assign another connection
     76Widget.objects.db = connections['other_widget_connection']
     77
    7178}}}
    7279
    7380 * Allow transaction decorators, etc to take optional connections argument. Without that argument, transactions will apply across all connections already in use.
    7481 
    75  * Move generation of schema manipulating sql (CREATE TABLE, etc) from django.core.management into backend.creation.
     82 * 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.
    7683
    7784 * 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.
Back to Top