Change executed raw mysql queries to return timezone aware datetimes.

2016-04-19 Thread Bryce Drennan
Request Change executed raw mysql queries to return timezone aware datetimes. Explanation Django 1.9 changed so that raw queries executed in mysql do not return timezone aware datetimes. Removing this feature now requires that all custom SQL queries involving datetimes have special handling

Re: Making Django more PaaS-friendly

2016-04-19 Thread Mike Bryant
On 11 April 2016 at 07:33, James Bennett wrote: > The main problem with this is that it's really not very elegant. But at the > moment I can't think of anything better, and so I'd like to throw the floor > open to ideas on nicer approaches to this. If one can't be found, I

Re: NumericListfilter or similar

2016-04-19 Thread John Griebel
I agree that we need a replacement; the current behaviour isn't all that useful, IMHO. My vote would for choice #2, after all it seems more natural (to me, at least), to think of numbers as a range, especially while searching. Option 1 seems less intuitive for a situation like this. +1 from me,

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

2016-04-19 Thread Tom Christie
> If you are using django-rest-framework, how would the fields counter work?. It would be a shame if only multi part and urlencoded uploads would have the benefit of these checks, while still allowing json, xml and others still be "exploited". Note I didn't really read the code changes

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

2016-04-19 Thread Tim Graham
My understanding is that Django doesn't do any parsing of JSON, XML, etc but rather simply makes such content available as a raw bystring, request.body. Therefore I don't see how Django could offer protection for the cases you mentioned. On Friday, April 15, 2016 at 6:43:27 PM UTC-4, Cristiano

Re: JsonpResponse subclass of HttpResponse helps easily create JSONP-encoded responses.

2016-04-19 Thread Joey Wilhelm
Agreed on discouraging (or at least not actively encouraging) the use of JSONP. Everything I've read on it has started with big "Do not try this at home!" warnings. I also very strongly agree on built-in support for CORS, especially elements of DRF getting more tightly integrated into the core. I

NumericListfilter or similar

2016-04-19 Thread Omer Korner
This is a proposal for a new ListFilter subclass. Currently, if you add a numeric field to list_filter, Django admin outputs all possible values of that field using AllValuesFieldListFilter. This can get ugly very quickly. For example, in my case, I have an application that manages transactions

Re: JsonpResponse subclass of HttpResponse helps easily create JSONP-encoded responses.

2016-04-19 Thread Tom Christie
JSONP is essentially a browser hack. There have been security issues raised around it, and we I don't believe we should encourage its usage by including it in Django core. (If anything we *might?* want to consider CORS for built-in support at some point.) I'd agree with Florian here - I'd rather