Changes between Initial Version and Version 1 of Ticket #32549, comment 5


Ignore:
Timestamp:
Mar 17, 2021, 1:24:09 PM (4 years ago)
Author:
jonathan-golorry

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #32549, comment 5

    initial v1  
    11We already shortcut logical operations between empty Q objects, so I view this more as an extension of that shortcutting (for legibility, not performance). I don't think it's fair to say it's backwards incompatible, since the simplified Q objects will be logically equivalent to the old ones. The expected outcome of Q object combinations is logical consistency, not a specific tree structure (as evidenced by `len((Q(x=1, y=2) | Q(x=1, y=2)).children == 1)`.
     2
     3The only place I can think of where this would affect the current Django internals is in simplifying the output of `Exists(...) | Q()` (and similar), which ends up running `Q(Exists(...)) | Q(Q())`.
    24
    35My original example shows why it's desirable to have `q.empty()` behave differently from `not bool(q)`. Empty Q objects are a potential security risk, but the standard way to check for them doesn't catch nested empty Q objects. #32554 doesn't actually build nested queries, it just uses this to avoid bugs with nested query inputs.
Back to Top