| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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
|
|
(23.7+).
Thanks Jacob Walls for the review.
|
|
|
|
GeneratedField.expression.
Thanks to Simon Charette for the suggestion and review.
|
|
Rewrapped long docstrings and block comments to 79 characters + newline
using script from https://github.com/medmunds/autofix-w505.
|
|
Manually reformatted some long docstrings and comments that would be
damaged by the to-be-applied autofixer script, in cases where editorial
judgment seemed necessary for style or wording changes.
|
|
Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
Co-authored-by: Adam Johnson <me@adamj.eu>
Co-authored-by: Sarah Boyce <42296566+sarahboyce@users.noreply.github.com>
|
|
This is not a properly supported feature yet and should be revisited by
refs #35957.
|
|
part of CompositePrimaryKey on SQLite.
|
|
field.
PostgreSQL versions 16.5 and above no longer permit the use
of a USING clause when changing the type of a generated column.
|
|
While AlterUniqueTogether has been documented to be still allowed in historical
migrations for the foreseeable future it has been crashing since 2abf417c815c20
was merged because the latter removed support for Meta.index_together which the
migration framework uses to render models to perform schema changes.
CreateModel(options["unique_together"]) was also affected.
Refs #27236.
Co-authored-by: Simon Charette <charette.s@gmail.com>
|
|
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>
|
|
|
|
True on PostgreSQL."
This reverts commit 9cf9c796be8dd53bc3b11355ff39d65c81d7be6d due to a crash on Oracle
as it didn't allow multiple indexes on the same field.
|
|
PostgreSQL.
|
|
constraint.
This is the exact same issue as refs #30408 but for creating a model with a
constraint containing % escapes instead of column addition. All of these issues
stem from a lack of SQL and parameters separation from the BaseConstraint DDL
generating methods preventing them from being mixed with other parts of the
schema alteration logic that do make use of parametrization on some backends
(e.g. Postgres, MySQL for DEFAULT).
Prior to the addition of Field.db_default and GeneratedField in 5.0
parametrization of DDL was never exercised on model creation so this is
effectively a bug with db_default as the GeneratedField case was addressed by
refs #35336.
Thanks Julien Chaumont for the report and Mariusz Felisiak for the review.
|
|
OperationTests.test_rename_m2m_field_with_2_references() test on Oracle.
|
|
ManyToManyField.through references on SQLite.
Thank you to dennisvang for the report and Jase Hackman for the test.
Co-authored-by: Jase Hackman <jase.hackman@zapier.com>
|
|
|
|
referencing rename field.
Thanks Sarah Boyce for the report and Simon Charette for the
implementation idea.
|
|
referenced by GeneratedField.expression.
Thank you to Simon Charette for the review.
|
|
|
|
|
|
Once the deprecation period ends CheckConstraint.check() can become the
documented method that performs system checks for BaseConstraint
subclasses.
|
|
Field.db_default accepts either literal Python values or compilables
(as_sql) and wrap the former ones in Value internally.
While 1e38f11 added support for automatic resolving of output fields for
types such as str, int, float, and other unambigous ones it's cannot do
so for all types such as dict or even contrib.postgres and contrib.gis
primitives.
When a literal, non-compilable, value is provided it likely make the
most sense to bind its output field to the field its attached to avoid
forcing the user to provide an explicit `Value(output_field)`.
Thanks David Sanders for the report.
|
|
https://github.com/psf/black/releases/tag/24.1.0
|
|
each operation.
|
|
unique constraint on the same fields.
|
|
Regression in f333e3513e8bdf5ffeb6eeb63021c230082e6f95.t
Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
Co-authored-by: David Sanders <shang.xiao.sanders@gmail.com>
|
|
Regression in f333e3513e8bdf5ffeb6eeb63021c230082e6f95.
|
|
Regression in 7414704e88d73dafbcfbb85f9bc54cb6111439d3.
|
|
non-nullable.
|
|
|
|
|
|
Thanks Adam Johnson and Paolo Melchiorre for reviews.
Co-Authored-By: Lily Foote <code@lilyf.org>
Co-Authored-By: Mariusz Felisiak <felisiak.mariusz@gmail.com>
|
|
|
|
with db_table.
|
|
db_table on SpatiaLite.
|
|
Special thanks to Hannes Ljungberg for finding multiple implementation
gaps.
Thanks also to Simon Charette, Adam Johnson, and Mariusz Felisiak for
reviews.
|
|
Proper escaping of % in string literals used when defining constaints
was attempted (a8b3f96f6) by overriding quote_value of Postgres and
Oracle schema editor. The same approach was used when adding support for
constraints to the MySQL/MariaDB backend (1fc2c70).
Later on it was discovered that this approach was not appropriate and
that a preferable one was to pass params=None when executing the
constraint creation DDL to avoid any form of interpolation in the first
place (42e8cf47).
When the second patch was applied the corrective of the first were not
removed which caused % literals to be unnecessary doubled. This flew
under the radar because the existings test were crafted in a way that
consecutive %% didn't catch regressions.
This commit introduces an extra test for __exact lookups which
highlights more adequately % doubling problems but also adjust a
previous __endswith test to cover % doubling problems (%\% -> %%\%%).
Thanks Thomas Kolar for the report.
Refs #32369, #30408, #30593.
|
|
This ensures that constraint violations are tested in isolation from
each other as an IntegrityError only ensures a least one constraint is
violated.
For example, the assertion added in 42e8cf4 break both the
name_constraint_rhs and the rebate_constraint constraints and thus
doesn't constitute a proper regression test. Refs #32369.
|
|
CheckConstraint if not supported.
The new logic mirrors the logic in SchemaEditor._delete_check_sql()
added in 68ef274bc505cd44f305c03cbf84cf08826200a8.
Thanks Tim Graham for the report.
|
|
same name.
|
|
Thanks Jared Chung, Tom Carrick, David Smith, Nick Pope, and Mariusz
Felisiak for reviews.
Co-authored-by: Mariusz Felisiak <felisiak.mariusz@gmail.com>
Co-authored-by: Nick Pope <nick@nickpope.me.uk>
|
|
MySQL < 8.0.16.
|
|
self-referential.
|
|
fields referenced by foreign key on PostgreSQL.
|
|
SQLite < 3.20.
|
