On Fri, Oct 17, 2008 at 5:07 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > Either this becomes a django standard, every code that might update database > on GET doing something like: > > connection.use_master() > try: > ... # something that updates db > finally: > connection.revert() > > or we pray/discard this approach of scaling altogether.
I love the smell of false dilemmas in the morning. So, you all know the old joke: A man goes to the doctor and says, "Doctor, it hurts when I hit my head with this hammer." So the doctor says, "Well, then, stop doing it!" Except in this case it's: A developer goes to the django-dev list and says, "Django devs, my application breaks when I assume that GET requests never do DB writes." So the Django devs say, "Well, then, stop assuming that!" If, however, you really want to keep hitting yourself in the head with that hammer, your best course is to take steps on your own -- steps which do not involve rewriting Django to suit the peculiarities of your situation -- to ensure that nothing in your setup does a DB write on a GET. Fortunately, if you're truly concerned about scaling you'll already have moved away from DB-backed sessions, so that's one potential problem gone. And the auth middleware and auth context processor probably get tossed as well, in favor of more efficient solutions suited to what you actually need. At which point the "DB write on a GET" problem suddenly starts to disappear (gasp and amazement!)... -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
