#34824: If to_fields or from_fields of ForeignObject is an array type, two
migration records will be generated.
-------------------------------------+-------------------------------------
Reporter: puc_dong | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 4.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by puc_dong:
Old description:
> Our data platform involves many tables and uses a lot of ForeignObject
> fields. Many tables do not have foreign key associations. We found that
> if from_fields or to_fields is configured as an array type, without
> changing the table structure, if makemigrations is executed, a new
> migration record will be generated twice.
>
> In the first generated migration file, from_fields and to_fields are both
> array types, and generate_altered_fields will type-convert the
> from_fields and to_fields values under the current Model ForeignObject
> field into tuple types. Resulting in inconsistent comparisons and
> generating new migration file records
>
> {{{
> from_fields = getattr(new_field, "from_fields", None)
> if from_fields:
> from_rename_key = (app_label, model_name)
> new_field.from_fields = tuple(
> [
> self.renamed_fields.get(
> from_rename_key + (from_field,), from_field
> )
> for from_field in from_fields
> ]
> )
> new_field.to_fields = tuple(
> [
> self.renamed_fields.get(rename_key + (to_field,), to_field)
> for to_field in new_field.to_fields
> ]
> )
> ...
> if old_field_dec != new_field_dec and old_field_name == field_name:
> ...
> AlterField...
> }}}
>
>
> No error will be reported the third time, because the second
> makemigrations will be saved as tuple types into the migration file,
> which will be consistent with the next conversion.
>
> operation record:
>
> [https://github.com/RelaxedDong/Images/assets/38744096/513e7021-bc2f-
> 4f7e-aa51-188cdebceb00]
> [https://github.com/RelaxedDong/Images/assets/38744096/3be6e3b9-ec0c-
> 4fa8-9fd9-bd04082747c9]
> [https://github.com/RelaxedDong/Images/assets/38744096/445fdd17-6c69-4e48-bb38-be9c11defe1b]
New description:
Our data platform involves many tables and uses a lot of ForeignObject
fields. Many tables do not have foreign key associations. We found that if
from_fields or to_fields is configured as an array type, without changing
the table structure, if makemigrations is executed, a new migration record
will be generated twice.
In the first generated migration file, from_fields and to_fields are both
array types, and generate_altered_fields will type-convert the from_fields
and to_fields values under the current Model ForeignObject field into
tuple types. Resulting in inconsistent comparisons and generating new
migration file records
{{{
from_fields = getattr(new_field, "from_fields", None)
if from_fields:
from_rename_key = (app_label, model_name)
new_field.from_fields = tuple(
[
self.renamed_fields.get(
from_rename_key + (from_field,), from_field
)
for from_field in from_fields
]
)
new_field.to_fields = tuple(
[
self.renamed_fields.get(rename_key + (to_field,), to_field)
for to_field in new_field.to_fields
]
)
...
if old_field_dec != new_field_dec and old_field_name == field_name:
...
AlterField...
}}}
No error will be reported the third time, because the second
makemigrations will be saved as tuple types into the migration file, which
will be consistent with the next conversion.
operation record:
[https://github.com/RelaxedDong/Images/assets/38744096/513e7021-bc2f-
4f7e-aa51-188cdebceb00]
[https://github.com/RelaxedDong/Images/assets/38744096/3be6e3b9-ec0c-
4fa8-9fd9-bd04082747c9]
[https://github.com/RelaxedDong/Images/assets/38744096/445fdd17-6c69-4e48-bb38-be9c11defe1b]
I try to solve this problem:https://github.com/django/django/pull/17238
--
--
Ticket URL: <https://code.djangoproject.com/ticket/34824#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018a78b421fc-29c67cf3-df6e-464e-b31a-934576d78ce2-000000%40eu-central-1.amazonses.com.