Re: settings.DEFAULT_CONTENT_TYPE incompatibility with admin

+1 Le jeudi 12 janvier 2017 08:11:09 UTC-5, Florian Apolloner a écrit : > > > > On Thursday, January 12, 2017 at 11:56:49 AM UTC+1, Marc Tamlyn wrote: >> >> DEFAULT_CONTENT_TYPE does sound like a setting which shouldn't exist. >> > > +1 > -- You received this message because you are subscribed

Re: user_login_failed and user_logged_in signals sent at different levels

You are right. I was confusing the login view with the login method. The more concrete problem was that Django REST framework calls authenticate directly and user_login_failed is sent but never user_logged_in. I realize though that some of the authentication methods provided by an API don't hav

Re: user_login_failed and user_logged_in signals sent at different levels

On Thursday, January 12, 2017 at 11:16:01 PM UTC+1, Federico Bond wrote: > > Since backends may call authenticate directly without going through login, > perhaps it would be best to move the user_login_failed to `login` and let > custom backends implement both signals manually if they need them

Re: Django sum and filter does not work

Hi, You've reached the Django Developers list, the list we use for people who are working on Django itself. The list for asking questions about using Django is Django Users, at https://groups.google.com/forum/#!forum/django-users . Thanks, Adam On 12 January 2017 at 21:42, dheeraj saini wrote:

user_login_failed and user_logged_in signals sent at different levels

While working on a project that calls the `authenticate` function from contrib.auth directly, I noticed that the user_login_failed signal is sent from it but not user_logged_in. I looked into the code and indeed, the user_logged_in signal is only sent from the higher-level `login` function. I w

Django sum and filter does not work

What i am trying to do is Sale.objects.values('pro').annotate(total_value = Sum('effective_price')).filter(total_value__gt=Decimal('600.00')).order_by('total_value'); In orm it does not return anything but when i takes it query in sql and then execute in sql it returns results as i want. Ther

Re: SubQuery without using RawSQL

I like my bike sheds to be green. But I don't have a problem painting it red either. It seems red is the more popular colour, and that's fine. > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubsc

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

> "*Django promises API stability and forwards-compatibility since version 1.0. In a nutshell, this means that code you develop against a version of Django will continue to work with future releases*." were imho untrue. Perhaps the API stability statements are too strong and need some clarifica

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

Hello, thanks for your feedback, Actually this DCP layer is mainly aimed at backwards compatibility of dependencies : running, on the latest version of django (with maximal security bugfixes), older reusable apps which are incompatible with each-other, or with said latest version of Django.

Re: SubQuery without using RawSQL

Subquery is one word so the lowercase Q would be correct yes. I'm skewed from using SubQuery in my code for the last few months, so that looks fine to me, but let's not get into another query_set problem On 12 January 2017 at 13:11, Adam Johnson wrote: > I vote for Subquery - I wouldn't make a c

Re: SubQuery without using RawSQL

I vote for Subquery - I wouldn't make a class called SubTitle 😝 Also SubQuery somewhat implies it's a subclass of Query. I think Josh has been staring at Query for too long 😀 On 12 January 2017 at 12:30, Tim Graham wrote: > A question about the casing. Since "subquery" is one word, I wouldn't >

Re: settings.DEFAULT_CONTENT_TYPE incompatibility with admin

On Thursday, January 12, 2017 at 11:56:49 AM UTC+1, Marc Tamlyn wrote: > > DEFAULT_CONTENT_TYPE does sound like a setting which shouldn't exist. > +1 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To u

Re: data must be QuerySet-like (have count() and order_by()) or support list(data) -- NoneType has neither

Please avoid the temptation to use this mailing list as a second level support channel. Imagine if everyone did that. On Thursday, January 12, 2017 at 7:09:48 AM UTC-5, Ali khan wrote: > > Hi All, > I know this is not the platform and I apologize to bother you all. But > I've posted on stackover

Re: SubQuery without using RawSQL

A question about the casing. Since "subquery" is one word, I wouldn't camel case it like SubQuery. Any other opinions? Josh says, "I prefer the CamelCased SubQuery visually. Subquery looks strange to me, even if it technically can be one word." On Wednesday, April 20, 2016 at 3:06:06 AM UTC-4,

data must be QuerySet-like (have count() and order_by()) or support list(data) -- NoneType has neither

Hi All, I know this is not the platform and I apologize to bother you all. But I've posted on stackoverflow, to GitHub repo and google groups and still didn't get any response. https://groups.google.com/forum/#!topic/django-users/_g5eMm_0j8A https://github.com/bradleyayers/django-tables2/issues/40

Re: settings.DEFAULT_CONTENT_TYPE incompatibility with admin

DEFAULT_CONTENT_TYPE does sound like a setting which shouldn't exist. On 12 January 2017 at 10:53, Adam Johnson wrote: > Having reviewed the ticket a bit and thought about it, I've had two > thoughts: > >1. The current patch doesn't fix existing custom views > >

Re: settings.DEFAULT_CONTENT_TYPE incompatibility with admin

Having reviewed the ticket a bit and thought about it, I've had two thoughts: 1. The current patch doesn't fix existing custom views which the docs explain how to use, and I've seen used quite often.

Re: Adding UNION/INTERSECT/EXCEPT to the ORM

Jupp, sounds good to me too -- will see that I get the PR updated this afternoon On Thursday, January 12, 2017 at 1:20:04 AM UTC+1, charettes wrote: > > +1 to QuerySet.difference() > > Le mercredi 11 janvier 2017 17:00:12 UTC-5, sebleier a écrit : >> >> We cannot use the name "QuerySet.except()"