Changes between Version 2 and Version 3 of Ticket #32548, comment 6


Ignore:
Timestamp:
Mar 15, 2021, 3:23:26 PM (4 years ago)
Author:
jonathan-golorry

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #32548, comment 6

    v2 v3  
    55I point out `Q(Exists...) | Q(Q())` to show that the fragility of the special case is problematic and hard to catch. An internal optimization for nested empty Q objects can cause conditional expression combination to fail. That's why I'd like this patch to be focused on removing the special case and making Q objects more robust for all inputs, rather than only adding support for expressions. Both would make my future work on Q objects possible, but the current patch would put django in a better position for future development.
    66
    7 Edit: To clarify on my future work, I intend to add `.empty()` Q objects to detect nested empty Q objects -- such as `Q(Q())` -- and remove them from logical operations. This would currently cause a regression in `test_boolean_expression_combined_with_empty_Q`. Ultimately the goal is to add robust implementations of `Q.any()` and `Q.all()` that can't return empty Q objects that accidentally leak the entire table https://forum.djangoproject.com/t/improving-q-objects-with-true-false-and-none/851/9
     7Edit: To clarify on my future work, I intend to add `.empty()` to detect nested empty Q objects -- such as `Q(Q())` -- and remove them from logical operations. This would currently cause a regression in `test_boolean_expression_combined_with_empty_Q`. Ultimately the goal is to add robust implementations of `Q.any()` and `Q.all()` that can't return empty Q objects that accidentally leak the entire table https://forum.djangoproject.com/t/improving-q-objects-with-true-false-and-none/851/9
Back to Top