Dear Anssi,
Am 2015-11-22 um 13:53 schrieb Anssi Kääriäinen:
The author_count name suggested this was an aggregation. If this is just
a regular field, then things are a bit simpler. Note that negated
Q-object + filter and exclude() queries are the same thing.
[...]
There is a fix for exactly t
On Saturday, November 21, 2015, Carsten Fuchs wrote:
> Hi Anssi,
>
> Am 2015-11-21 um 12:50 schrieb Anssi Kääriäinen:
>
>> In summary, the imaginary query of comment 14
>>
>> Blog.objects.filter(entry__tag__name='django',
>> entry__author_count__ne=2)
>>
>>
>> This isn't a real q
I have to say, the lack of __ne is very inconsistent for people new to
django, but veterans at sql. It's just one more frustration point when
you're trying to learn a new ORM.
-Ben
On Friday, November 20, 2015 at 11:37:02 AM UTC-8, Carsten Fuchs wrote:
>
> Hi all,
>
> sorry if this is a stupid
I hadn't come across custom lookups in the docs. Thanks for the
explanation and a fix Marten, I appreciate it.
-A
On Sat, Nov 21, 2015 at 2:53 AM, Marten Kenbeek
wrote:
> The 'con' side argument is that it would create in inconsistency in the
> API, since we don't have any other negated lookup
Hi Anssi,
Am 2015-11-21 um 12:50 schrieb Anssi Kääriäinen:
In summary, the imaginary query of comment 14
Blog.objects.filter(entry__tag__name='django',
entry__author_count__ne=2)
This isn't a real query. There isn't a field author_count, the query
needs an annotation somewher
On Saturday, November 21, 2015, Carsten Fuchs wrote:
> Hi Marten,
>
> Am 2015-11-21 um 11:53 schrieb Marten Kenbeek:
>
>> The 'con' side argument is that it would create in inconsistency in the
>> API, since we don't have any other negated lookups either. If we can get
>> the same behaviour by fi
Hi Marten,
Am 2015-11-21 um 11:53 schrieb Marten Kenbeek:
The 'con' side argument is that it would create in inconsistency in the
API, since we don't have any other negated lookups either. If we can get
the same behaviour by fixing the current API, Django should not
introduce an unnecessary cons
The 'con' side argument is that it would create in inconsistency in the
API, since we don't have any other negated lookups either. If we can get
the same behaviour by fixing the current API, Django should not introduce
an unnecessary consistency. ("Closed as wontfix by core dev" is not an
argum
Am Samstag, 21. November 2015 02:27:42 UTC+1 schrieb Aaron C. de Bruyn:
>
> With all due respect, looking through the ticket and reading responses
> shows me that the 'pro' side has good use cases for __ne, and the 'con'
> side basically says "use exclude" or "a core committer close the ticket,
Hi James,
Am Samstag, 21. November 2015 02:56:45 UTC+1 schrieb James Bennett:
>
> 8 years later, I still think we should figure out how to make exclude() do
> what people expect it to do, rather than implement another lookup type that
> overlaps with it.
>
What really confuses me is how exclude
Hi Marcin,
Am Samstag, 21. November 2015 02:22:10 UTC+1 schrieb Marcin Nowak:
>
> On Friday, November 20, 2015 at 8:37:02 PM UTC+1, Carsten Fuchs wrote:
>>
>> sorry if this is a stupid question, but after having read
>> https://code.djangoproject.com/ticket/5763 and the discussions linked
>> fro
8 years later, I still think we should figure out how to make exclude() do
what people expect it to do, rather than implement another lookup type that
overlaps with it.
On Fri, Nov 20, 2015 at 7:27 PM, Aaron C. de Bruyn
wrote:
> With all due respect, looking through the ticket and reading respon
With all due respect, looking through the ticket and reading responses
shows me that the 'pro' side has good use cases for __ne, and the 'con'
side basically says "use exclude" or "a core committer close the ticket,
stop opening it" with no good reasoning or rationale behind it.
-A
On Fri, Nov 20
On Friday, November 20, 2015 at 8:37:02 PM UTC+1, Carsten Fuchs wrote:
>
> sorry if this is a stupid question, but after having read
> https://code.djangoproject.com/ticket/5763 and the discussions linked
> from it, why should __ne not be implemented?
>
>
Because Django ORM __ne SQLAlchemy.
B
Hi all,
sorry if this is a stupid question, but after having read
https://code.djangoproject.com/ticket/5763 and the discussions linked from
it, why should __ne not be implemented?
Without __ne, I'm experiencing the same problems that asmoore82 described
at https://code.djangoproject.com/ticke
15 matches
Mail list logo