| 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.
|
|
It has been superseded with .quote_name(), which ensures aliases are
always quoted.
|
|
This ensures all database identifiers are quoted independently of their orign
and most importantly that user provided aliases through annotate() and alias()
which paves the way for dropping the allow list of characters such aliases can
contain.
This will require adjustments to raw SQL interfaces such as RawSQL that might
make reference to ORM managed annotations as these will now be quoted.
The `SQLCompiler.quote_name_unless_alias` method is kept for now as an alias
for the newly introduced `.quote_name` method but will be duly deprecated in
a follow up commit.
|
|
get_placeholder_sql.
The lack of ability of the get_placeholder call chain to return SQL and
parameters separated so they can be mogrified by the backend at execution time
forced implementations to dangerously interpolate potentially user controlled
values.
The get_placeholder_sql name was chosen due to its proximity to the previous
method, but other options such as Field.as_sql were considered but ultimately
rejected due to its different input signature compared to Expression.as_sql
that might have lead to confusion.
There is a lot of overlap between what Field.get_db_prep_value and
get_placeholder_sql do but folding the latter in the former would require
changing its return signature to return expression which is a way more invasive
change than what is proposed here.
Given we always call get_db_prep_value it might still be an avenue worth
exploring in the future to offer a publicly documented interface to allow field
to take an active part in the compilation chain.
Thanks Jacob for the review.
|
|
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.
|
|
with periods.
Before, `order_by()` treated a period in a field name as a sign that it
was requested via `.extra(order_by=...)` and thus should be passed
through as raw table and column names, even if `extra()` was not used.
Since periods are permitted in aliases, this meant user-controlled
aliases could force the `order_by()` clause to resolve to a raw table
and column pair instead of the actual target field for the alias.
In practice, only `FilteredRelation` was affected, as the other
expressions we tested, e.g. `F`, aggressively optimize away the ordering
expressions into ordinal positions, e.g. ORDER BY 2, instead of ORDER BY
"table".column.
Thanks Solomon Kebede for the report, and Simon Charette and Jake Howard
for reviews.
|
|
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>
|
|
Thanks Adam Sołtysik for the implementation idea.
|
|
already-closed cursor.
|
|
explicit grouping.
Co-authored-by: Simon Charette <charette.s@gmail.com>
|
|
This is also applicable on CockroachDB.
|
|
|
|
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.
|
|
ManyToManyField was already excluded from fields, concrete_fields,
and local_concrete_fields in Options.
|
|
Follow-up to cb13792938f2c887134eb6b5164d89f8d8f9f1bd. Refs #34437.
|
|
Follow-up to 8ede411a81b40ca53362e6788601193c7e56a0cf.
|
|
via ForeignObject.
|
|
This required implementing UPDATE RETURNING machinery that heavily
borrows from the INSERT one.
|
|
FieldError is now emitted for invalid update calls involving reverse
relations, where previously they failed with AttributeError.
|
|
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().
|
|
Renamed existing methods and abstractions used for INSERT … RETURNING
to be generic enough to be used in the context of UPDATEs as well.
This also consolidates SQL compliant implementations on
BaseDatabaseOperations.
|
|
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.
|
|
values()/values_list().
Regression in 65ad4ade74dc9208b9d686a451cd6045df0c9c3a which allowed for
annotations to be SELECT'ed before model field references through
values()/values_list() and broke assumptions the select_for_update(of)
table infererence logic had about model fields always being first.
Refs #28900.
Thanks OutOfFocus4 for the report and Sarah for the test.
|
|
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.
|
|
|
|
Adding proper support for subquery right-hand-sides to TupleIn made it
obsolete.
|
|
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.
|
|
When all values of a field with a db_default are DatabaseDefault, which
is the case most of the time, there is no point in specifying explicit
DEFAULT for all INSERT VALUES as that's what the database will do anyway
if not specified.
In the case of PostgreSQL doing so can even be harmful as it prevents
the usage of the UNNEST strategy and in the case of Oracle, which
doesn't support the usage of the DEFAULT keyword, it unnecessarily
requires providing literal db defaults.
Thanks Lily Foote for the review.
|
|
Thanks Jacob Walls for the report and test.
|
|
field with QuerySet.update().
|
|
|
|
methods per deprecation timeline.
|
|
The previous logic was systematically attempting to retrieve last_insert_id
even for models without an AutoField primary key when they had a GeneratedField
on backends that can't return columns from INSERT.
The issue affected MySQL, SQLite < 3.35, and Oracle when the use_returning_into
option was disabled and could result in either crashes when the non-auto
primary key wasn't an IntegerField subclass or silent misassignment of bogus
insert ids (0 or the previous auto primary key insert value) to the first
defined generated field value.
|
|
This logic could only be exercised if the composite primary key included an
AutoField but it's not allowed yet (refs #35957).
It was also slightly broken as it expected the AutoField to always be the first
member of returning_fields.
|
|
Thanks Jacob Walls for the report and test and Csirmaz Bendegúz for the review.
|