On Fri, Oct 17, 2008 at 7:10 AM, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > To reiterate, I am proposing: "avoid, and if not possible, document" for DB > updates in GET, are you really saying you are against this? Is your logical > position "encourage" or "don't care/document"?
To reiterate, I am proposing: "as you're developing your application, pay attention to what's going on in the code and tailor your solutions accordingly." I've already made this point but I'll lay it out once again. Here is an exhaustive list of every view in Django which might do a DB write on a GET request: * All of them. As I said before, that's because of Django's configurability; it simply is not possible to produce a list people can trust, because if we did we'd almost immediately get someone (probably you) right back here saying "this view wasn't on the list but it ended up doing a write on a GET" based on what happens when you enable/disable various combinations of middlewares, decorators, etc. So the only truly safe answer is that every single GET request your application receives might do a DB write, and it's up to you -- you, Amit, since you know your needs and we don't -- to look at how you're using Django and configure things appropriately for your situation. > You have to make assumptions or/and read the source to evaluate any > solution. DB selection based on request method is the only obvious solution > I can come up with for scaling after exhausting caching options. Are you > ruling it out for django apps? If so what are the other solutions? If not, > should django not be a little accomodating about it? If you want to do DB selection based on the request method, *do it*. Just keep in mind that there is not and never will be a list of view functions which are labeled "these views, only these views, and no other views will ever do a DB write on a GET". Aside from the safe answer of "any of them can, depending on configuration", it's just not possible to produce such a list. It's also not worth trying to go back and rewrite everything in Django to try to conform to the easy assumptions you'd like to make about HTTP; there are too many useful and non-RFC-violating cases for writing some data on a GET. > I do not understand, when everywhere django tries so very hard in a > pragmatic sense to decouple things where it logically makes sense, then why > suddenly an ideological outburst of "because we are not violating any specs, > we refuse to even think". And this is where the histrionics take over and I sign out. If your first response to the discussion here is to say "Django developers refuse to even think about this", then honestly I don't have the first clue how to go about helping you. -- "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 -~----------~----~----~----~------~----~------~--~---
