On Wed, Oct 15, 2008 at 4:28 PM, Luke Plant <[EMAIL PROTECTED]> wrote: > It is not desirable to have Django try to enforce this, since GET > requests are allowed to have side effects, just not side effects that > "have the significance of taking an action other than retrieval" [1].
This is not about specs or what is allowed, rather what is there in actual django. And about implementation goals for django. It is possible to have a django(core+contrib apps shipped with django) with only SELECT queries in response for GET request. So far I have identified two places and their work arounds. Are there more? They should be avoided, and if not possible documented. Also I am talking about django core and contrib apps only [and hoping a SELECT only or workaround possible policy gets a official nod and voluntarily implemented by thirdparty developer apps]. > There are all kind of use cases where it is good to be able to track > the fact that the user has made a retrieval. (Amazon and 7digital > track pages you've visited, for instance, to help you keep track of > items you are interested in). This is not django core requirement, rather a django project's application logic, the reason I am distinguishing these two is because I have mostly written the application logic and when it presents me with a problem I would rewrite it to add some work around. That is not equally easy with django core, third party apps. Also I am not saying alter must not be allowed, just that it be considered as a necessary evil if at all, and scaling simplicity consideration should be weighed in when ever a new (sql) data alter on GET is considered. > Second, even if you could enforce it at the database level, there are > many other ways you could have side effects e.g. mail, filesystem. I am only thinking of database replication scenario and problems/gotchas that may be there in django if I blindly split traffic based on request method, in case of the database being the bottleneck. mail causes no concern, and file system would be problem but only if there are more than one webserver, and thus for the sake one issue per thread we can ignore it for now, focusing only on whats required to scale database server, which is big enough a problem. -- 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 -~----------~----~----~----~------~----~------~--~---
