In Python, keyword arguments must normally be valid identifiers (i.e.,
variable names that follow Python's naming rules). However, Python dicts
can have keys that aren't valid identifiers, like "foo-bar" or "123foo".
This commit ensures that keyword arguments that are nt valid
identifiers, are properly handled when deconstructing an object.
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>
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>
Before, the full suite of system checks was run by these commands
regardless if requires_system_checks had been overridden.
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>
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.
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.
