I suppose I'll chime in here since we actually wrote master/slave replication code on Curse.
Our approach: - read_cursor and write_cursor exist. write_cursor is what cursor would point ot. - get queries all use the read cursor - saves all use the write cursor - we had a list of database connections, which stored the same settings, just in a tuple format - reading I believe used something like itertools.cycle but I can't honestly say without looking at the code Beyond this, the database itself should handle writing the objects to the slaves. Django shouldn't even bother. In regards to multiple databases in general. it is my feeling that even if it is not good practice, Django _NEEDS_ to support a model being attached to a database other than the default. So if you have mydjango_blogs, and mydjango_forums databases, my Forum model always goes to the write db when it queries, and same for blogs. I myself like a Meta solution to this as it makes sense. In MySQL as well, you can optimize things, so that if they use the same connection, you can just query on that database. It's select X from mydatabase.mytable. I'm not sure if something similar exists in other database engines. On Jun 16, 9:05 pm, mengel <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
