On Saturday, November 21, 2015, Carsten Fuchs <carsten.fu...@cafu.de> 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 fixing the current API, Django should not >> introduce an unnecessary consistency. >> > > I think that this is where the communication problem is: > > The "con" side seems to see a problem in the current API regarding > exclude() (personally, about what it is I only have a vague idea from older > linked discussions: NOT(...) vs. "proper" negation) and argues that fixing > the problem solves the issue and avoids inconsistency in the API brought by > the introduction of __ne. > > The "pro" side sees a problem in functionality when __ne is lacking, and > cannot see how the "con" side's arguments would help. The problem in > functionality is detailed in > https://code.djangoproject.com/ticket/5763#comment:14, which essentially > quotes (possibly an older version of) > https://docs.djangoproject.com/en/1.8/topics/db/queries/#spanning-multi-valued-relationships > and shows a related example where exclude() cannot replace __ne. As we/I > cannot see how fixing/changing exclude() would help in this situation, we > keep asking about __ne. ;-) > > 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 somewhere. So, I don't think this argument is convincing without the annotation (note that the place of the annotation matters). In addition, providing example data and the expected results would be great, too. The discussion seems to miss a real definition of what exactly the ne lookup should do. There are two ways to implement ne, one is as a complement of exact, another is as the != operator. In SQL the first one is "col != val OR col IS NULL", the latter one is just "col != val". The complement is already achieved with .exclude(col__exact=val), so we don't need a duplicate API for that. But we don't have any way of doing the != operator alone for nullable fields, and I don't see a fundamental reason why we couldn't add it. The biggest problem is that the new __ne lookup isn't actually a complement of __exact, and that could be confusing. But this is the case for lt and gte, too. The underlying problem here is SQL's three-valued boolean logic. Unsuprisingly, this feature of SQL causes a lot of confusion. - Anssi > seems quasi not be possible to implement in today's Django (but probably > with your suggestion below). > > Anyway, with the new lookup API, it has become trivial for any project >> to implement the __ne lookup. It is the first example in the how-to >> guide: >> https://docs.djangoproject.com/en/dev/howto/custom-lookups/#a-simple-lookup-example >> . >> > > Thanks, I'll definitively check and try this out, I didn't know it before! > > Best regards, > Carsten > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/565054EA.40508%40cafu.de > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALMtK1HgO7dXgKH8QoKrCcRzUa-t7%2Be6WPdPUOk4hSn_eYNb6Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
