My Django 1.8 application uses a third-party application ( django-avatar ) whose model contains ImageField. I also use custom DEFAULT_FILE_STORAGE (S3BotoStorage from django-storageages-redux ) in my project settings.py file. As a result, every time I run manage.py migrate , I get this warning about the avatar application:
There are changes in your models that are not yet reflected in the migration, and therefore will not be applied. Run "manage.py makemigrations" to perform new migrations, and then re-run "manage.py migrate" to apply them.
... because the initial avatar migration refers to the Django default FileSystemStorage. Running makemigations creates a new 0002 migration in the avatar application to make its ImageField repository match my project setup:
... migrations.AlterField( model_name='avatar', name='avatar', field=models.ImageField(storage=storages.backends.s3boto.S3BotoStorage(), max_length=1024, upload_to=avatar.models.avatar_file_path, blank=True), ),
The problem is that this new migration is created in the avatar installed in python sites sites outside my project (therefore the external git control is not available for deployment, etc.).
What is the correct way to handle migration for a third-party application using ImageField (or FileField) in a project with custom DEFAULT_FILE_STORAGE? I thought:
Just ignore the warning. The transition to changing the storage does not actually affect the database schema, and since my DEFAULT_FILE_STORAGE project was S3BotoStorage from the very beginning, data migration is not required.
Use settings.MIGRATION_MODULES to move the migration avatar to my project. (And then carefully transfer all future migration avatars to my copy - which seems error prone.) [EDIT: this comment on the django-users mailing list suggests this is the wrong approach.]
Ask the django-avatar (or django-storages-redux) developers to change ... what? (BTW, S3BotoStorage is already deconstructible - this is not a problem.)
Or...?
source share