#32554: Add Q.empty(), Q.TRUE, Q.FALSE, Q.any(), and Q.all()
-------------------------------------+-------------------------------------
     Reporter:  jonathan-golorry     |                    Owner:  jonathan-
                                     |  golorry
         Type:  New feature          |                   Status:  closed
    Component:  Database layer       |                  Version:  dev
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:  wontfix
     Keywords:  Q objects, any, all  |             Triage Stage:
                                     |  Unreviewed
    Has patch:  1                    |      Needs documentation:  1
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):

 * status:  assigned => closed
 * resolution:   => wontfix


Comment:

 Thanks for this ticket, however I have mixed-feelings. Django API is
 already massive. IMO new hooks will make `Q` expressions more confusing
 and are not necessary per se. `Q.any()` and `Q.all()` can be replaced with
 `reduce()` (that's how we do this in Django itself, see
 
[https://github.com/django/django/blob/7c08f26bf0439c1ed593b51b51ad847f7e262bc1/django/contrib/admin/options.py#L1032
 an example]). I don't see why the new API should be preferred over an
 example with `reduce()` in
 [https://docs.djangoproject.com/en/dev/topics/db/queries/#complex-lookups-
 with-q-objects docs]. It has already been
 [https://github.com/django/django/pull/13798#issuecomment-767492096
 pointed out] that we need a good example of building `Q()` dynamically.

 About `Q.TRUE` and `Q.FALSE`, these constants are really tricky and niche.
 I don't believe that folks will not how to use them properly (I don't see
 immediate and wide use). Moreover, I'm not sure why Django should
 recommend the `pk__in=[]` lookup (and not e.g. `pk=-1`), everything
 depends on the context. It is so niche that folks should choose on their
 own.


 I strongly believe that we need a good example of building `Q()`
 dynamically with the existing API, rather than adding yet another method
 to do the same.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/32554#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.4366cc8d5a664a1618cf2b7afe810893%40djangoproject.com.

Reply via email to