It seems that what you may want is something like http://softwaremaniacs.org/soft/mysql_replicated/
(its in Russian that i cannot read and one of the links has the source :) master slave DB engine (for Mysql) I modified it to force a master call for everything that was not a "SELECT" in the final query, and once you force it to the master (or it auto forces to the master) it will stay there for the duration of the request to deal with the asynchronous nature of a master-slave pair. bo On Oct 15, 12:50 am, "Amit Upadhyay" <[EMAIL PROTECTED]> wrote: > Usecase: for scaling a website(bottlenecked on database), one of the > first thing to do after caching and other optimizations is to split > requests to go to master/slave replicated database servers. One way of > doing it is based on request.METHOD[1], GET requests going to slave, > and POSTs going to master. > > Problem: django has a few instances where a GET leads to database > changes. 1. session creation(INSERT) 2. > User.get_and_delete_messages(DELETE). And probably others. > > Question: 1. is the expectation that GET request should only do SELECT > reasonable? 2. if 1, then should django enforce it? [So far using non > db based session backend, and allowing delete for auth_messages from > "GET machines" and living with "a message appears more than once" is > what I am doing]. > > [1]: For example throughhttp://www.djangosnippets.org/snippets/1141/ > > -- > Amit Upadhyay > Vakow!www.vakow.com > +91-9820-295-512 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
