| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
Thanks Adam Sołtysik for the implementation idea.
|
|
already-closed cursor.
|
|
This is also applicable on CockroachDB.
|
|
|
|
|
|
This required implementing UPDATE RETURNING machinery that heavily
borrows from the INSERT one.
|
|
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.
|
|
Rewrapped long docstrings and block comments to 79 characters + newline
using script from https://github.com/medmunds/autofix-w505.
|
|
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.
|
|
|
|
Adding proper support for subquery right-hand-sides to TupleIn made it
obsolete.
|
|
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.
|
|
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.
|
|
|
|
By building the list of placeholders for each inserted fields once it
doesn't have to be looked up for each inserted rows twice.
The query_values_10000.benchmark.QueryValues10000.time_query_values_10000 ASV
benchmark showed a 5% speed up for 10k items on SQLite for a single field
insertion. Larger performance gains are expected when more fields are involved.
|
|
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>
|
|
containing "__".
Regression in b0ad41198b3e333f57351e3fce5a1fb47f23f376.
Refs #34013. The initial logic did not consider that annotation aliases
can include lookup or transform separators.
Thanks Gert Van Gool for the report and Mariusz Felisiak for the review.
|
|
a query.
|
|
While refs #34125 focused on the SQL correctness of slicing of union of
potentially empty queries it missed an optimization opportunity to avoid
performing a query at all when all queries are empty.
Thanks Lucidiot for the report.
|
|
It was added in 01d440fa1e6b5c62acfa8b3fde43dfa1505f93c6 to
prevent "RuntimeError: OrderedDict mutated during iteration".
That particular issue was fixed in d660cee5bc68b597503c2a16f3d9928d52f93fb4
but the issue could remain in Join.as_sql() subclasses.
Co-authored-by: Simon Charette <charette.s@gmail.com>
|
|
Follow up from f7f5edd50d03e8482f8a6da5fb5202b895d68cd6.
|
|
Previously, only the selected column aliases would be propagated and
annotations were ignored.
|
|
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.
|
|
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.
|
|
co-authored-by: Gordon <gordon.wrigley@gmail.com>
co-authored-by: Simon Charette <charette.s@gmail.com>
|
|
co-authored-by: Keryn Knight <keryn@kerynknight.com>
co-authored-by: Natalia <124304+nessita@users.noreply.github.com>
co-authored-by: David Smith <smithdc@gmail.com>
co-authored-by: Paolo Melchiorre <paolo@melchiorre.org>
|
|
https://github.com/psf/black/releases/tag/24.1.0
|
|
Thanks Eugene Morozov and Ben Nace for the reports.
|
|
GeneratedField.output_field with backend converters.
Regression in d9de74141e8a920940f1b91ed0a3ccb835b55729.
This is a long standing issue, however it caused a crash of
GeneratedFields for all output fields that have backend-specific
converters when the RETURNING clause is not supported
(MySQL and SQLite < 3.35).
That's why severity was exacerbated.
|
|
3.39.
On SQLite < 3.39, this forces a GROUP BY clause with a HAVING clause
when no grouping is specified.
Co-authored-by: Simon Charette <charette.s@gmail.com>
|
|
SQLCompiler.
Performance regression in 278881e37619278789942513916acafaa88d26f3.
Co-authored-by: David Smith <smithdc@gmail.com>
|
|
self-referential subqueries if supported.
|
|
window expression.
Regression in f387d024fc75569d2a4a338bfda76cc2f328f627.
Co-authored-by: Jannis Vajen <jvajen@gmail.com>
|
|
Regression in 278881e37619278789942513916acafaa88d26f3 caused by a lack
of expression copying when an OrderBy expression is explicitly provided.
Thanks Jannis Vajen for the report and regression test.
|
|
Used the same approach as for #34176 by using selected expressions
position to prevent ambiguous aliases in collisions.
Thanks henribru for the report.
Regression in 04518e310d4552ff7595a34f5a7f93487d78a406.
|
|
This avoids conceptual collisions with the notion of indices.
|
|
FilteredRelation.
|
|
Regression in 3d734c09ff0138441dfe0a59010435871d17950f.
Thanks Raphaël Stefanini for the report.
|
|
Regression in b7b28c7c189615543218e81319473888bc46d831.
Refs #31377.
Thanks Shai Berger for the report and reviews.
test_aggregation_subquery_annotation_values_collision() has been
updated as queries that are explicitly grouped by a subquery should
always be grouped by it and not its outer columns even if its alias
collides with referenced table columns. This was not possible to
accomplish at the time 10866a10 landed because we didn't have compiler
level handling of colliding aliases.
|
|
|
|
FilteredRelations to the OneToOneField.
|
|
SQLCompiler.get_related_selections() to avoid redefinition.
|
