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
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
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
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
> 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
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.
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
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…
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
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
10 matches
Mail list logo