id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
37060	AlterField doesn't propagate type changes through transitive attname-based to_field references	Andrea Zanotto	Andrea Zanotto	"When a relation uses an attname-based `to_field` such as `primary_id`, Django accepts and resolves it correctly, but `AlterField` does not always propagate type changes through transitive dependencies.

Minimal example:
{{{
    class Primary(models.Model):
        code = models.CharField(max_length=5, unique=True)

    class Related(models.Model):
        primary = models.OneToOneField(
            Primary,
            to_field=""code"",
            on_delete=models.CASCADE,
        )

    class Dependent(models.Model):
        related = models.ForeignKey(
            Related,
            to_field=""primary_id"",
            on_delete=models.CASCADE,
        )
}}}
If `Primary.code.max_length` is changed from 5 to 11, Django correctly updates `Related.primary_id`, but `Dependent.related_id` remains at `varchar(5)` instead of widening to `varchar(11)`.
== Behavior
Using:
- `to_field=""primary""` works correctly
- `to_field=""primary_id""` does not
However, Django currently accepts `primary_id` as a valid `to_field` reference because relation resolution uses `Options.get_field()`, and `get_field()` maps both the field name and the relation attname to the same field object.
That means if `ForeignKey(..., to_field=""primary_id"")` is accepted and resolved as valid, schema alteration should handle it the same way as `to_field=""primary""`.
== Cause
The schema dependency walk in `django/db/backends/base/schema.py` uses `_related_non_m2m_objects()` and `_is_relevant_relation()` to discover fields whose database type must be updated.
Before the fix, `_is_relevant_relation()` compared only the altered field's `name` against `field.to_fields`.
In the example above, the recursive step compares:
- altered field name: `primary`
- dependent field `to_fields`: `[""primary_id""]`
So the dependency is missed even though both names refer to the same remote field.
As a result, the transitive dependent column is excluded from schema propagation.
== Expected behavior
Altering `Primary.code` from `max_length=5` to `max_length=11` should also widen:
- `Related.primary_id`
- `Dependent.related_id`
regardless of whether the dependent relation was declared with:
- `to_field=""primary""`
- `to_field=""primary_id""`
== Fix
Treat attname-based `to_field` values as equivalent to the actual remote field when determining whether a relation depends on the altered field.
In practice, this means resolving each `to_field` through `remote_model._meta.get_field(...)` and comparing field identity, instead of only comparing raw field names.
SQLite also needs the same recursive dependency logic in its schema editor override when rebuilding related tables after altering unique fields."	Bug	assigned	Migrations	5.2	Normal		schema alterfield to_field attname foreignkey		Unreviewed	1	0	0	0	0	0