| Age | Commit message (Collapse) | Author |
|
and random order_by strings.
Run this example:
```python
User.objects.values("is_staff").annotate(latest=Max("date_joined")).order_by("-latest").count()
```
You should see the following exception:
```
django.core.exceptions.FieldError: Cannot resolve keyword '-latest' into field.
```
Regression in 2ce5cb0f7a4618dfdc5f5c10e53e2e9b9543d298.
|
|
Thanks Simon Charette and Tim Graham for reviews, and Jason Hall for a
prior iteration.
|
|
contain periods.
This prevents failures at the database layer, given that aliases in the
ON clause are not quoted.
Systematically quoting aliases even in FilteredRelation is tracked in
https://code.djangoproject.com/ticket/36795.
|
|
control characters.
Control characters in FilteredRelation column aliases could be used for
SQL injection attacks. This affected QuerySet.annotate(), aggregate(),
extra(), values(), values_list(), and alias() when using dictionary
expansion with **kwargs.
Thanks Solomon Kebede for the report, and Simon Charette, Jacob Walls,
and Natalia Bidart for reviews.
|
|
values()/values_list() calls.
Signed-off-by: JaeHyuck Sa <wogur981208@gmail.com>
|
|
Signed-off-by: JaeHyuck Sa <wogur981208@gmail.com>
|
|
explicit grouping.
Co-authored-by: Simon Charette <charette.s@gmail.com>
|
|
missing from explicit grouping."
This reverts commit ea3a71c2d09f8281d8a50ed20e40e1fb13db5cd9.
The implementation was flawed, as self.group_by contains Cols, not aliases.
|
|
explicit grouping.
Co-authored-by: Simon Charette <charette.s@gmail.com>
|
|
and extra() against SQL injection in column aliases on MySQL/MariaDB.
Thanks sw0rd1ight for the report.
Follow up to 93cae5cb2f9a4ef1514cf1a41f714fef08005200.
|
|
Follow-up to cb13792938f2c887134eb6b5164d89f8d8f9f1bd. Refs #34437.
|
|
Follow-up to 8ede411a81b40ca53362e6788601193c7e56a0cf.
|
|
via ForeignObject.
|
|
column aliases.
Thanks Eyal Gabay (EyalSec) for the report.
|
|
values()/values_list().
Thanks Jacob Walls and Simon Charette for tests.
Signed-off-by: SaJH <wogur981208@gmail.com>
|
|
values().
|
|
against composite pks.
Follow-up to 8561100425876bde3be4b2a22324655f74ff9609.
Co-authored-by: Simon Charette <charette.s@gmail.com>
|
|
Manually reformatted some comments and docstrings where autofix_w505.py
changed the meaning of the formatting.
|
|
Rewrapped long docstrings and block comments to 79 characters + newline
using script from https://github.com/medmunds/autofix-w505.
|
|
Unintentional support existed only on SQLite and Oracle.
|
|
|
|
selects too many columns.
|
|
Regression in 65ad4ade74dc9208b9d686a451cd6045df0c9c3a.
Refs #28900.
Thanks Jeff Iadarola for the report and tests.
Co-Authored-By: OutOfFocus4 <jeff.iadarola@gmail.com>
|
|
and references.
Regression in 65ad4ade74dc9208b9d686a451cd6045df0c9c3a.
Refs #28900
Thanks Patrick Altman for the report.
|
|
Non-tuple exact and in lookups have specialized logic for subqueries that can
be adapted to properly assign select mask if unspecified and ensure the number
of involved members are matching on both side of the operator.
|
|
The original queryset._next_is_sticky() call never had the intended effect as
no further filtering was applied internally after the pk__in lookup making it
a noop.
In order to be coherent with how related filters are applied when retrieving
objects from a related manager the effects of what calling _next_is_sticky()
prior to applying annotations and filters to the queryset provided for
prefetching are emulated by allowing the reuse of all pre-existing JOINs.
Thanks David Glenck and Thiago Bellini Ribeiro for the detailed reports and
tests.
|
|
|
|
FilteredRelation.
|
|
Thanks Lily Foote and Simon Charette for reviews and mentoring
this Google Summer of Code 2024 project.
Co-authored-by: Simon Charette <charette.s@gmail.com>
Co-authored-by: Lily Foote <code@lilyf.org>
|
|
Just like normal queries, combined queries' outer references might fully
resolve before their reference is assigned its final alias.
Refs #29338.
Thanks Antony_K for the report and example, and thanks Mariusz Felisiak
for the review.
|
|
Aggregation optimization didn't account for not referenced set-returning annotations on Postgres.
Co-authored-by: Simon Charette <charette.s@gmail.com>
|
|
against JSON fields.
Thanks Eyal (eyalgabay) for the report.
|
|
|
|
|
|
|
|
This should ensure it never drifts from Query.selected while maintaining
backward compatibility.
|
|
Previously the order was always extra_fields + model_fields + annotations with
respective local ordering inferred from the insertion order of *selected.
This commits introduces a new `Query.selected` propery that keeps tracks of the
global select order as specified by on values assignment. This is crucial
feature to allow the combination of queries mixing annotations and table
references.
It also allows the removal of the re-ordering shenanigans perform by
ValuesListIterable in order to re-map the tuples returned from the database
backend to the order specified by values_list() as they'll be in the right
order at query compilation time.
Refs #28553 as the initially reported issue that was only partially fixed
for annotations by d6b6e5d0fd4e6b6d0183b4cf6e4bd4f9afc7bf67.
Thanks Mariusz Felisiak and Sarah Boyce for review.
|
|
This avoids manual .annotations and .append_annotation_mask manipulations.
|
|
By always including related objects in the select mask via adjusting the
defer logic (_get_defer_select_mask()), it becomes possible for
select_related_descend() to treat forward and reverse relationships
indistinctively.
This work also simplifies and adds comments to
select_related_descend() to make it easier to understand.
|
|
While refs #34612 surfaced issues with reverse one-to-one fields
deferrals, it missed that switching to storing remote fields would break
self-referential relationships.
This change switches to storing related objects in the select mask
instead of remote fields to prevent collisions when dealing with
self-referential relationships that might have a different directional
mask.
Despite fixing #21204 introduced a crash under some self-referential
deferral conditions, it was simply not working even before that as it
aggregated the sets of deferred fields by model.
Thanks Joshua van Besouw for the report and Mariusz Felisiak for the
review.
|
|
operators.
Thanks Alan for the report.
Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
|
|
Regression in 59f475470494ce5b8cbff816b1e5dafcbd10a3a3.
|
|
https://github.com/psf/black/releases/tag/24.1.0
|
|
early return.
This avoids costly hashing.
Thanks Anthony Shaw for the report.
Co-Authored-By: Simon Charette <charette.s@gmail.com>
|
|
Thanks Mark Zorn for the report.
Regression in 59f475470494ce5b8cbff816b1e5dafcbd10a3a3.
|
|
Regression in 59bea9efd2768102fc9d3aedda469502c218e9b7.
Thanks Marcin for the report.
|
|
|
|
While this isn't a regression it's clear that similar logic should be
applied when dealing with lists of expressions passed as a lookup value.
|
|
Adjustments made to solve_lookup_type to defer the resolving of
references for summarized aggregates failed to account for similar
requirements for lookup values which can also reference annotations
through Aggregate.filter.
Regression in b181cae2e3697b2e53b5b67ac67e59f3b05a6f0d.
Refs #25307.
Thanks Sergey Nesterenko for the report.
|
|
expressions containing subqueries.
Regression in 59bea9efd2768102fc9d3aedda469502c218e9b7,
complements e5c844d6f2a4ac6ae674d741b5f1fa2a688cedf4.
Refs #28477, #34551.
Thanks Haldun Komsuoglu for the report.
|