Code

Changes between Version 17 and Version 18 of MultipleDatabaseSupport


Ignore:
Timestamp:
09/11/08 08:57:41 (6 years ago)
Author:
simon
Comment:

added initial requirements and problems to solve

Legend:

Unmodified
Added
Removed
Modified
  • MultipleDatabaseSupport

    v17 v18  
    33''See PreviousMultipleDatabaseBranch for information on a previous attempt at adding this.'' 
    44 
    5 A more recent discussion about multi-db support can be seen on this thread: http://groups.google.com/group/django-developers/browse_thread/thread/9f0353fe0682b73 
     5The most recent discussion about multi-db support can be seen on this thread: http://groups.google.com/group/django-developers/browse_thread/thread/9f0353fe0682b73 
     6 
     7== Requirements == 
     8 
     9An ideal solution would address all of the following: 
     10 
     11 * '''Different models/applications living on different databases''', for example a 'blog' application on db1 and a forum application on db2. This should include the ability to assign a different database to an existing application without modifying it, e.g. telling Django where to keep the django.contrib.auth.User table. 
     12 * '''Master-slave replication''', where writes go to a single master while reads are spread across one or more slaves. Due to replication lag it may sometimes be necessary for reads that directly follow a related write to be directed to the master. 
     13 * '''Talking to existing or legacy databases''' while still allowing newer functionality to be developed on a different database dedicated solely to Django. 
     14 * '''Sharding''', where rows within a single model are spread across multiple databases for improved write performance. 
     15 
     16== Problems to solve == 
     17 
     18 * '''Connection definitions''' - how are multiple database connections defined? Does this new method replace Django's existing DATABASE_* family of settings? 
     19 * '''Connection selection''' - what is the API for telling Django which database a query should be executed against? 
     20 * '''Associating connections with models''' - for the common case where a model is assigned to a different database, how is that assignment made? How can existing apps such as contrib.auth be assigned to a different database in a clean way? This is one facet of the connection selection problem. 
     21 * '''Related managers''' - how do we deal with the case when the User model lives on one database but its related BlogEntrys live on a different database? 
     22 * '''Joins across different databases''' - do we try to get these working? If not, how do we detect them and what kind of error or warning do we present?