Menu
My Django 1.8 app uses a third-party app (django-avatar) whose model contains an ImageField. I'm also using a custom DEFAULT_FILE_STORAGE (S3BotoStorage from django-storages-redux) in my project's settings.py. As a result, every time I run manage.py migrate, I get this warning about the avatar app:
Your models have changes that are not yet reflected in a migration, and so won't be applied. Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.
... because avatar's initial migration references Django's default FileSystemStorage. Running makemigrations creates a new 0002 migration in the avatar app, to make its ImageField's storage match my project setting:
...
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, this new migration is created in avatar installed in python's site-packages, outside my project (so outside git control, unavailable for deployment, etc.).
What's the right way to handle migrations for a third-party app that uses an ImageField (or FileField) in a project with custom DEFAULT_FILE_STORAGE? I've considered:
Just ignore the warning. The migration to change storage doesn't actually affect the DB schema, and since my project's DEFAULT_FILE_STORAGE has been S3BotoStorage since the start, no data migration is needed.
Use settings.MIGRATION_MODULES to move avatar's migrations into my project. (And then carefully port over every future avatar migration 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) maintainers to change... what? (BTW, S3BotoStorage is already deconstructible -- that's not the problem.)
Or...?
447
you can either: temporarily remove your migration, execute python manage.py migrate, add again your migration and re-execute python manage.py migrate. Use this case if the migrations refer to different models and you want different migration files for each one of them.
So the difference between makemigrations and migrate is this: makemigrations auto generates migration files containing changes that need to be applied to the database, but doesn't actually change anyhting in your database. migrate will make the actual modifications to your database, based on the migration files.
Migrations are stored within the <app_name>/migrations directory. You can check out some default migrations here, that's default auth migrations, but there are more.
The answer is... Ask the django-avatar maintainers to fix it.
If you want to simply use the default storage you should pass None or django.core.files.storage.default_storage to ImageField. In this case storage kwarg will not be passed to the field in the migration.
I created PR to fix this.
50
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
