On May 22, 9:59 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> 1. Replication - being able to send all of my writes to one master
> machine but spread all of my reads over several slave machines.
> 2. Sharding - being able to put User entries 1-1000 on DB1, whereas
> User entries 1001-2000 live on DB2 and so on.
It seems to me this isn't beyond doing in the current setup; but I'm
not sure I understand
the underlying mechanism well enough. For case 1, you need an object
class that
creates two (or more) (apparently identical) Models.model classes, one
attached to each database, based on the field types declared as class
variables:
* on searches, it picks one of the model classes to search
* on saves, saves the same data to each object class in turn
For case 2, it's very similar, except you need to run the query on all
sides (unless
you can tell it should only go to one) building a chained query-set
union type to hold
the result, and for saves pick the right model to save to based on
the condition.
In each case, the underlying models have to be tied to the right
databases, but this can
be done using the mechanism in the proposal so far..
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
