On Tuesday 04 July 2017 20:39:37 tay...@cedar.com wrote: > I am having some trouble figuring out the best way to remove model > fields in Django. If I remove a field from a model and then run > makemigrations, it creates a RemoveField operation in a migration. > That is great, but if I decide to run the migration before releasing > the new code, the existing code will break (for a short time between > running the migration and releasing the new code) because the old > code is still querying for the removed column (Django queries for all > columns by default). I could run the migration after the release, but > that won't work if I also have an AddField operation because the new > code needs the new column, so it needs to be run before. I am > wondering if anyone has solved this issue?
You're fixing this in the wrong place. This is for the project manager and technical lead to fix. If you have dependencies between releases that break the product if either one of them is not applied, then you need to move components of those releases so that it doesn't happen. Also, migrations exist to have a consistent code versus database. A developer's task to "remove field A", isn't simply to remove the field from the model and makemigrations. Her task isn't done till all querysets that reference that field by name are refactored. -- Melvyn Sopacua -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/2791819.D1gAZz8dtj%40devstation. For more options, visit https://groups.google.com/d/optout.
