Re: __ne, #5763

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

Re: __ne, #5763

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

Re: __ne, #5763

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

Re: __ne, #5763

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

Re: __ne, #5763

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

Re: __ne, #5763

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

Re: __ne, #5763

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

Re: __ne, #5763

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

Re: __ne, #5763

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,

Re: __ne, #5763

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

Re: __ne, #5763

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

Re: __ne, #5763

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

Re: __ne, #5763

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

Re: __ne, #5763

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.

__ne, #5763

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