Thanks, Russell. That's similar to the approach we were thinking of
implementing. Hopefully we'll have a straw man to share shortly.
Matt
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://g
That's a great addition to the project! Congratulations.
I couldn't hold myself from adding my two cents to this topic.
Having the custom user model available on
"django.contrib.auth.models.User" would be transparent for third party apps
and south migrations.
This is kinda the way django-shop
Hi Matt,
I'm not aware of any community maintained solution for this. However,
interestingly, what you've suggested (including some contextual stack
information in a query comment) is something that was suggested by Cal
Henderson at the very first DjangoCon.
I'm not sure Ned's "global request obj
Hello,
While I'm working on HttpResponse, I'd like to resolve two related tickets.
Here's my plan for discussion.
#6527 is about normalizing how HttpResponse deals with iterators. For more
background, see part 1 of the first email of this thread.
Let's take an HttpResponse instantiated with a
>From time to time the pager goes off, and I need to find the source of a
given query hitting MySQL. It might be poorly performing, or flooding MySQL
in high volume. In any case, I'd love some instrumentation that could point
me at a lead in my Django site that's more specific than a given user
