Changes between Initial Version and Version 2 of Ticket #24067


Ignore:
Timestamp:
Dec 31, 2014, 7:54:38 PM (9 years ago)
Author:
doepunk
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #24067

    • Property Component Uncategorized → Migrations

  • Ticket #24067 – Description

    initial v2  
    1212}}}
    1313
    14 I'm unsure what's going on here. But shouldn't renaming involve the automatic deletion of the old name and replacing the foreign keys with the new database table keys? All without a need for confirmation. Or at least if there are no foreign keys as in my case, the confirmation seems unnecessary and it only makes it harder to run the migration unsupervised and it introduces a potential error source. Assuming that all data from the old table were copied to the new table and all foreign key relationships copied and updated as well, I don't see a use case for keeping the old table and "related objects" around. And as for the case that there were any changes in relationships reflected in the Models (other than the name change) this could be detected and confirmed in the makemigrations stage. (For example if there were still references to OldName in the code when OldName no longer exists as a class, this would result in a syntax error, or if a Foreign Key attribute to OldModel was deleted and not replaced with NewModel Foreign Key it's just akin to a field deletion). It just seems more reproducible to keep all confirmations in the makemigration stage.
     14I'm unsure what's going on here. But shouldn't renaming involve the automatic deletion of the old name and replacing the foreign keys with the new database table keys? All without a need for confirmation. Or at least if there are no foreign keys as in my case, the confirmation seems unnecessary and it only makes it harder to run the migration unsupervised and it introduces a potential error source. Assuming that all data from the old table were copied to the new table and all foreign key relationships copied and updated as well, I don't see a use case for keeping the old table and "related objects" around. And as for the case that there were any changes in relationships reflected in the Models (other than the name change) this could be detected and confirmed in the makemigrations stage. (For example if there were still references to OldName in the code when OldName no longer exists as a class, this would result in an exception, or if a Foreign Key attribute to OldModel was deleted and not replaced with NewModel Foreign Key it's just akin to a field deletion). It just seems more reproducible to keep all confirmations in the makemigration stage.
Back to Top