| Age | Commit message (Collapse) | Author |
|---|
|
Setting "check" in OPTIONS["pool"] previously raised TypeError because the
PostgreSQL backend always passed check= to ConnectionPool() and unpacked
**pool_options on top, regardless of CONN_HEALTH_CHECKS. The user's callable
now takes precedence via setdefault(); pool_options is copied first to avoid
mutating the user's settings dict.
|
|
Co-authored-by: Jacob Walls <jacobtylerwalls@gmail.com>
|
|
When we adjusted UNKNOWN handling for CheckConstraint in refs #33996 we assumed
that all usage of Q.check would benefit from this approach.
However while CHECK constraints enforcement do ignore conditions involving NULL
that resolve to UNKNOWN it's not the case for other type of constraints such as
UNIQUE ones.
Given how UNKNOWN should be treated depends on the callers context it appears
that a better strategy for COALESCE wrapping is to force them to apply it if
necessary.
Thanks Drew Shapiro for the report.
|
|
Added new constant django.db.models.fields.BLANK_CHOICE_LABEL for
an accessible and translatable blank choice label in forms.
Deprecated django.db.models.fields.BLANK_CHOICE_DASH constant.
Added the immediately deprecated transitional setting
USE_BLANK_CHOICE_DASH.
Co-Authored-By: Marijke Luttekes <mail@marijkeluttekes.dev>
|
|
|
|
This is a more attractive target for alteration than all of QuerySet.__init__().
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
managers and related_names.
Clashes were only detected for self-referential relationships, i.e. ForeignKey("self").
Refs #22977. Bug in 6888375c53476011754f778deabc6cdbfa327011.
Thanks JaeHyuckSa for the thorough review!
|
|
Thanks Simon Charette and Tim Graham for reviews, and Jason Hall for a
prior iteration.
|
|
|
|
Based on Daniele Varrazzo's comment in https://github.com/psycopg/psycopg/issues/1273#issuecomment-3986829769
|
|
It has been superseded with .quote_name(), which ensures aliases are
always quoted.
|
|
feature flag.
Now that user provided aliases are systematically quoted there is no need to
disallow the usage of the dollar sign on Postgres.
|
|
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.
|
|
This avoids two isinstance() calls per UUID value.
|
|
Oracle.
|
|
|
|
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.
|
|
|
|
provided.
Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
|
|
manager.get_queryset() always returns freshly instantiated per-instance
QuerySet which doesn't need subsequent cloning.
Based on work originally done by Anssi Kääriäinen and Tim Graham.
|
|
Multiple calls are idempotent assuming they're balanced. Also, multiple
calls to disable cloning followed by a single call to re-enable cloning
will subsequently cause clones to occur - it is not a stack, just a
toggle.
@contextlib.contextmanager is intentionally not used for performance
reasons:
- decorator takes 1.1µs to execute, or 2µs if used correctly in a
`with ...:` statement
- custom class takes 300ns to execute, or 900ns if used correctly in a
`with ...:` statement
Based on work originally done by Anssi Kääriäinen and Tim Graham.
|
|
|
|
It's useful on MongoDB.
|
|
|
|
Needed on MongoDB.
|
|
on SQLite.
The "spawn" and "forkserver" multiprocessing modes were affected.
|
|
|
|
failure on Oracle.
Oracle's SQL parser does not allow ORDER BY in components of a union in some
cases, so xfail this test until an exception can be raised.
|
|
Thanks Simon Charette for the idea.
|
|
`DatabaseOperations.check_expression_support()`.
|
|
Avoided reconstructing the same tuples on every call by defining them as module-level constants.
|
|
deferred annotations.
Provide a wrapper for safe introspection of user functions on Python 3.14+.
Follow-up to 601914722956cc41f1f2c53972d669ddee6ffc04.
|
|
default delimiter.
|
|
Needed by MongoDB.
|
|
|
|
|
|
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.
|
|
|
|
Regression in 94680437a45a71c70ca8bd2e68b72aa1e2eff337. Refs #27222.
During INSERT operations, `field.pre_save()` is called to prepare values
for db insertion. The `add` param must be `True` for `auto_now_add`
fields to be populated. The regression commit passed `False`, causing
`auto_now_add` fields to remain `None` when used by other fields, such
as `upload_to` callables.
Thanks Ran Benita for the report.
|
|
Co-authored-by: Simon Charette <charette.s@gmail.com>
Co-authored-by: Jacob Walls <jacobtylerwalls@gmail.com>
|
|
Ever since the beginning of Django's migration framework, there's been a
bit of an inconsistency on how index_together and unique_together values
have been stored on the ModelState[^1].
It's only really obvious, when looking at the current code for
`from_model()`[^2] and the `rename_field()` state alteration code[^3].
The problem in the autodetector's detection of the `*_together` options
as raised in the ticket, reinforces the inconsistency[^4]: the old value
is being normalized to a set of tuples, whereas the new value is taken
as-is.
Why this hasn't been caught before, is likely to the fact, that we
never really look at a `to_state` that comes from migration operations
in the autodetector. Instead, in both usages in Django[^5], [^6] the
`to_state` is a `ProjectState.from_apps()`. And that state is
consistently using sets of tuples and not lists of lists.
[^1]: https://github.com/django/django/commit/67dcea711e92025d0e8676b869b7ef15dbc6db73#diff-5dd147e9e978e645313dd99eab3a7bab1f1cb0a53e256843adb68aeed71e61dcR85-R87
[^2]: https://github.com/django/django/blob/b1ffa9a9d78b0c2c5ad6ed5a1d84e380d5cfd010/django/db/migrations/state.py#L842
[^3]: https://github.com/django/django/blob/b1ffa9a9d78b0c2c5ad6ed5a1d84e380d5cfd010/django/db/migrations/state.py#L340-L345
[^4]: https://github.com/django/django/blob/b1ffa9a9d78b0c2c5ad6ed5a1d84e380d5cfd010/django/db/migrations/autodetector.py#L1757-L1771
[^5]: https://github.com/django/django/blob/2351c1b12cc9cf82d642f769c774bc3ea0cc4006/django/core/management/commands/makemigrations.py#L215-L219
[^6]: https://github.com/django/django/blob/2351c1b12cc9cf82d642f769c774bc3ea0cc4006/django/core/management/commands/migrate.py#L329-L332
|
|
|
