Re: Backwards compatibility and field validation

2013-10-18 Thread Marc Tamlyn
I think Anssi summed up my feelings on this very well, in particular with the issues with update(). Similarly create() would also bypass as it does not call save() AFAIK. Given these commonly used approaches do not work, and that the name of the method - save() - implies only saving to the databas

Re: #18659 -- Deprecating request.REQUEST

2013-10-18 Thread Marc Tamlyn
Seems to me an intermediary step is to add request.DATA (then maybe request.QUERY eventually) as a long term movement towards being better http. It isn't something we should do overnight. I noticed this patch is now in 1.7 and 1.9 will remove request.REQUEST. Marc On 18 Oct 2013 14:55, "Tom Chris

Re: Backwards compatibility and field validation

2013-10-18 Thread Cal Leeming [Simplicity Media Ltd]
Sorry please ignore my last email, my email client went a bit weird and sent the draft whilst I was still editing/thinking. Here is the proper version; This is yet another reason why I don't think it would be reasonable to expect field validation within the model. If the validations were done usi

Re: Backwards compatibility and field validation

2013-10-18 Thread Cal Leeming [Simplicity Media Ltd]
This is yet another reason why I don't think it would be reasonable to expect field validation within the model. I also think that introducing such a check would not only lure the user into a false sense of security If the validations were done using DB constraints (as per Anssi's reply) then thi

Re: #18659 -- Deprecating request.REQUEST

2013-10-18 Thread Tom Christie
> but perhaps we should provide better names for `request.GET` and `request.POST` at the same time Sure, I'd absolutely agree in principle, and for what it's worth REST framework provides `.QUERY_PARAMS` and `.DATA` attributes on the request which are recommended instead of using `.GET` and `.P

Re: #18659 -- Deprecating request.REQUEST

2013-10-18 Thread François Schiettecatte
Hi Just wanted to pitch in as a user of django. I have used request.REQUEST before for a very specific need but I would +1 for it to go. The question I would have though is for PUT and DELETE methods, would the parameters just wind up in request.POST? Maybe this suggests that renaming request.

Re: Backwards compatibility and field validation

2013-10-18 Thread Florian Apolloner
On Friday, October 18, 2013 12:03:42 AM UTC+2, lucmult wrote: > > I think it's reasonable to assume that by default we want our data to be > consistent. > I disagree, everything which isn't coming from user input should not need validation, since you really __should__ know what you are putting

Re: Backwards compatibility and field validation

2013-10-18 Thread Florian Apolloner
On Friday, October 18, 2013 4:28:21 AM UTC+2, Karen Tracey wrote: > > Wasn't there also concern for double validation performed during form > clean and then model instance save? > Yes, technically we would probably have to track the validation state per field and also track changes to it etc…

Re: #18659 -- Deprecating request.REQUEST

2013-10-18 Thread James Aylett
On Wednesday, October 16, 2013 5:48:09 PM UTC+1, Aymeric Augustin wrote: > While pour point is technically valid as far as request.GET and > request.POST are concerned, in practice they're so commonly used as a > metonymy for HTTP GET and HTTP POST that it's worth having a strong stance > on

Re: Possible idea for removing global state in Django.

2013-10-18 Thread Anssi Kääriäinen
On Friday, October 18, 2013 1:31:07 AM UTC+3, Shai Berger wrote: > > On Thursday 17 October 2013 08:34:48 Aymeric Augustin wrote: > > > > For instance, thread locals are strictly equivalent to regular variables > in > > tests because they are single threaded (with a handful of exceptions). > B