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
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
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,
> 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
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
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
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
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