Changes between Version 1 and Version 2 of Ticket #32548, comment 6
- Timestamp:
- Mar 15, 2021, 2:49:07 PM (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #32548, comment 6
v1 v2 4 4 5 5 I 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. 6 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