diff options
| author | Clifford Gama <cliffygamy@gmail.com> | 2025-12-15 23:36:24 +0200 |
|---|---|---|
| committer | Jacob Walls <jacobtylerwalls@gmail.com> | 2025-12-16 17:47:10 -0500 |
| commit | ba7f49c32118ecbe03c53414c71caafd2d5d2bd2 (patch) | |
| tree | 7795acf0a3e1ccb03b643e3c34e7790d70d1092c /tests/user_commands | |
| parent | be26ac85fdf06a7a8a655f6e7000b1263890717d (diff) | |
[6.0.x] Fixed #36800 -- Restored ManyToManyField renaming in BaseDatabaseSchemaEditor.alter_field().
Regression in f9a44cc0fac653f8e0c2ab1cdfb12b2cc5c63fc2.
Now that ManyToManyField is no longer concrete the decision of whether or not
it should be altered, which is also relied on by field renaming, should take
into consideration name changes even if it doesn't have a column associated
with it, as auto-created many-to-many relationship table names are a base of it.
Note that there is room for optimization here where a rename can be entirely
avoided if ManyToManyField.db_table remains stable between .name changes, just
like we do with Field.db_column remaining stable, but since this is a
regression and meant to be backported the current patch focuses on correctness
over further improvements.
Thanks Josik for the report.
Co-authored-by: Simon Charette <charette.s@gmail.com>
Backport of 6cc1231285a20b11058143f8cb0a6b4b3999b23a from main.
Diffstat (limited to 'tests/user_commands')
0 files changed, 0 insertions, 0 deletions
