Changes between Initial Version and Version 1 of Ticket #23581
- Timestamp:
- Oct 1, 2014, 4:49:28 PM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #23581 – Description
initial v1 22 22 Which is slightly strange since the initial migration never set a DEFAULT, so there is nothing to DROP. 23 23 24 I first noticed this working with django-cms (see https://github.com/divio/django-cms/issues/3479). In some cases when I attempt to make a migration for an unrelated app, `makemigrations` will forcefully create a migration for the `cms` app because the settings.CMS_TEMPLATES choices have changed. It then makes this automatically created migration a dependency for the migration I actually intended to create. There doesn't appear to be a way to avoid this.24 I first noticed this working with django-cms (see https://github.com/divio/django-cms/issues/3479). In some cases when I attempt to make a migration for an unrelated app, `makemigrations` will forcefully create a migration for the `cms` app because the settings.CMS_TEMPLATES choices have changed. It then makes this automatically created migration (which is output in the virtualenv e.g. `env/src/django-cms/cms/migrations_django`) a dependency for the migration I actually intended to create. There doesn't appear to be a way to avoid this. This means I now have a migration I actually need for one of my apps that is completely dependent on me creating a migration for a third party app, which I don't directly control, resulting in migrations that are broken for other developers. 25 25 26 26 This can also happen when the choices differ in development vs deployment, Django will complain: