| Age | Commit message (Collapse) | Author |
|
Thank you Mike Edmunds for the review.
|
|
functools.cached_property.
Since Python 3.12, `functools.cached_property` no longer takes a lock
(https://github.com/python/cpython/issues/87634), which was the main
objection to using it instead of Django's own implementation.
`Prefetch(to_attr=...)` and the admindocs model detail page now accept
`functools.cached_property` as well as Django's own `cached_property`.
Co-authored-by: Natalia <124304+nessita@users.noreply.github.com>
|
|
|
|
expressions.
Regression in 9b8e4c6d7d47f7b2e96817ba334e9fd53c10a0df.
|
|
a key is outside its integer range.
Oracle's JSON_EXISTS() rejects an array-subscript literal this long
with ORA-40598/JZN-00211.
|
|
is outside PostgreSQL's int4 range.
|
|
Refs #36689. 9b8e4c6d7d wrapped every Value() rhs param of a JSONIn lookup
in JSON_EXTRACT()/JSON_VALUE() assuming it was already JSON-serialized.
That only holds for Value(..., JSONField()); a bare Value("primitive") gets
an inferred non-JSON output_field (e.g. CharField), so its compiled param
was a raw primitive, not JSON text.
JSONIn.resolve_expression_parameter() now JSON-encodes the Value's raw
.value itself whenever its output_field isn't JSONField.
As a side effect, this also fixes Value(True)/Value(False) in __in, which
were previously compared as raw Python bools against the JSON-extracted
lhs and never matched.
Thanks Jacob Walls for the report.
Regression in 9b8e4c6d7d47f7b2e96817ba334e9fd53c10a0df.
Co-authored-by: Jacob Walls <jacobtylerwalls@gmail.com>
|
|
get_prep_value() tested for ":" before coercing the value to a string,
which crashed with a TypeError for non-string values such as
ipaddress.IPv4Address and ipaddress.IPv6Address instances, even though
to_python() accepts them.
|
|
Negated lookups rely on `Field.null` to match rows where the value is
`NULL`. This behavior was lost when `null=True` was removed from
`GeneratedField` definitions to silence `fields.W225`.
|
|
GeneratedField in test models.".
This reverts commit 968f3f96373e028f1486d135e38331fcd0e3a0ca.
|
|
Updated references to RemovedInDjango70Warning to use the new warning,
and adjusted references to "Django 7.0" to "Django 2028".
RemovedInDjango70Warning remains importable as an alias of the same
class, so existing warning filters and except clauses in third-party
code keep working across the rename.
|
|
Many (~70) tests assert a specific row order for querysets whose SQL has no
ORDER BY. SQL standard does not define that order.
On PostgreSQL the rows usually arrive in physical storage order, which
on a freshly loaded table matches insertion order -- so these assertions
pass by coincidence rather than by contract. That breaks when rows are
updated or deleted and the space is reused, or when the planner picks a
different access path such as an index scan. A test like this can start
failing with no change to Django or to the test itself.
The patch made sure that most of these tests do not
rely on unspecified unordered selection order.
|
|
precision.
Thank you Matt Cooper for the report and Mariusz Felisiak for the review.
|
|
This commit deprecates the "fetch all relations" form of
`QuerySet.select_related()` due to its poor performance characteristics, and
updates several tests relying on that feature to ignore the new warning.
|
|
|
|
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>
|
|
|
|
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.
|
|
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>
|
|
Test coverage is preserved because the tests only verify that generated
fields can produce NULL values when the source field is nullable.
This addresses system check warnings in the test suite after
6025eab3c509b4de922117e16866bbfe0ee99aa6.
|
|
Thanks Jacob Walls for the report.
|
|
tests/model_fields/test_jsonfield.py
|
|
(23.7+).
Thanks Jacob Walls for the review.
|
|
values in Value.
Previously, only strings were supplied with an output_field when wrapping
direct value iterable elements in Value expressions for ExpressionList. This
caused problems for __in lookups on JSONField when using expressions
alongside direct values, as JSONField values can have different types which
need to be adapted by the field's get_db_prep_value().
Refs #36689.
Thanks Jacob Walls for the review.
|
|
|
|
Oracle.
Added a JSONIn lookup to handle correct serialization and extraction
for JSONField top-level __in queries on backends without native JSON
support. KeyTransformIn now subclasses JSONIn.
Co-authored-by: Jacob Walls <jacobtylerwalls@gmail.com>
Thanks Jacob Walls for the report and review.
|
|
|
|
Key and index lookups are exempt from the deprecation.
Co-authored-by: Jacob Walls <jacobtylerwalls@gmail.com>
|
|
Thanks Jacob Walls for the review.
|
|
Follow-up to 0de89b6f8d4d8f5fd232d6c5412260b0d79a760a.
|
|
ManyToManyField was already excluded from fields, concrete_fields,
and local_concrete_fields in Options.
|
|
MySQL only supports the ->> when used directly against columns, this can be
inferred by the presence of lhs.output_field.model as model bounds fields are
directly tied to columns.
Purposely don't systematically switch to using JSON_QUOTE(JSON_EXTRACT(...))
as there might be functional indices out there that rely on the SQL remaining
stable between versions.
Thanks Jacob Tavener for the report.
|
|
This required implementing UPDATE RETURNING machinery that heavily
borrows from the INSERT one.
|
|
|
|
Previously save() would crash with an attempted forced update message, and both
save(force_insert=True) and bulk_create() would crash with DoesNotExist errors
trying to retrieve rows with an empty primary key (id IS NULL).
Implementing deferred field model instance copying might be doable in certain
cases (e.g. when all the deferred fields are db generated) but that's not
trivial to implement in a backward compatible way.
Thanks Adam Sołtysik for the report and test and Clifford for the review.
|
|
|
|
|
|
https://github.com/psf/black/releases/tag/25.1.0
|
|
|
|
databases that don't support primitives in JSONFields.
For example on Oracle < 21c.
|
|
Avoids reports of bulk_update() sending Cast expressions
to JSONField.get_prep_value().
Co-authored-by: Simon Charette <charette.s@gmail.com>
|
|
In order for Expression.relabeled_clone to work appropriately its
get_source_expressions method must return all resolvable which wasn't the case
for Lookup when its right-hand-side is "direct" (not a compilable).
While refs #22288 added support for non-literals iterable right-hand-side
lookups it predated the subclassing of Lookup(Expression) refs #27021 which
could have been an opportunity to ensure right-hand-sides are always resolvable
(ValueList and ExpressionList).
Addressing all edge case with non-resolvable right-hand-sides would require
a significant refactor and deprecation of some parts of the Lookup interface so
this patch only focuses on FieldGetDbPrepValueIterableMixin (In and Range
lookups) by making sure that a right-hand-side containing resolvables are dealt
with appropriately during the resolving phase.
Thanks Aashay Amballi for the report.
|
|
|
|
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.
|
|
DatabaseOperations.adapt_decimalfield_value().
Regression in e9814029f570bd0866dc859147bca90340bcc913.
Thanks Simon Charette for advice and review.
|
|
usage on Oracle.
Thanks Seokchan Yoon for the report, and Mariusz Felisiak and Sarah
Boyce for the reviews.
|
|
|