On Wed, 2008-10-15 at 13:20 +0530, Amit Upadhyay wrote: [...] > One way of > doing it is based on request.METHOD[1], GET requests going to slave, > and POSTs going to master.
Be careful, though, since that can lead to problems. Every time you write to a master, it takes a finite amount of time for all the slaves to be updated. So if subsequent GETs depend on the result of the initial POST (which is quite common, since you often want to view the results of a recent POST, such as a comment), then those GETs need to go to the master as well. However, in other situations, it's quite a valid split to make. If, for example, the writes are being done by once source and the reads are coming from another direction. > 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? No. GET requests shouldn't result in any significant data changes, but that's a "SHOULD NOT", not a "MUST NOT" requirement. One relevant portion of RFC 2616 is section 13.9, where the concept is explained in terms of cacheable and non-cacheable requests. Things like updating a last-accessed time if the server is hit, or updating a page count are reasonable cases where a GET might have a side-effect that results in altering some data. Something like updating a last-accessed time also effectively satisfies the idempotency "should" requirement for GET, since multiple requests for the same resource will leave the system in the same state as if only the last operation had been performed (updating something like a hit counter doesn't satisfy this, but that's why things like section 13.9 exist). Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
