Изменения Django не отражаются в миграции с ImageField и пользовательским хранилищем

В моем приложении Django 1.8 используется стороннее приложение (django-avatar), модель которого содержит ImageField. Я также использую собственный DEFAULT_FILE_STORAGE (S3BotoStorage из django-storages-redux) в настройках моего проекта .py. В результате каждый раз, когда я запускаю manage.py migrate, я получаю следующее предупреждение о приложении аватара:

В ваших моделях есть изменения, которые еще не отражены в миграции, поэтому не будут применены. Запустите manage.py makemigrations, чтобы выполнить новые миграции, а затем повторно запустите manage.py migrate, чтобы применить их.

... потому что первоначальная миграция аватара ссылается на FileSystemStorage по умолчанию Django. Запуск makemigrations создает новую миграцию 0002 в приложении аватара, чтобы хранилище ImageField соответствовало настройкам моего проекта:

...
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),
),

Проблема в том, что эта новая миграция создается в аватаре, установленном в пакетах сайта python, вне моего проекта (т.е. вне контроля git, недоступен для развертывания и т. Д.).

Как правильно обрабатывать миграции для стороннего приложения, которое использует ImageField (или FileField) в проекте с настраиваемым DEFAULT_FILE_STORAGE? Я считал:

  • Просто игнорируйте предупреждение. Миграция в хранилище изменений фактически не влияет на схему БД, и поскольку мой проект DEFAULT_FILE_STORAGE с самого начала был S3BotoStorage, перенос данных не требуется.

  • Используйте settings.MIGRATION_MODULES, чтобы перенести миграции аватара в мой проект. (А затем аккуратно переносите каждую будущую миграцию аватара в мою копию - что кажется подверженным ошибкам.) [EDIT: этот комментарий в списке рассылки django-users предполагает, что это неправильный подход.]

  • Попросите разработчиков django-avatar (или django-storerages-redux) изменить ... что? (Кстати, S3BotoStorage уже деконструируемый - проблема не в этом.)

  • Or...?


django django-migrations django-storage
person medmunds    schedule 15.09.2015    source источник
comment
Привет, medmunds, я в настоящее время поддерживаю django-avatar, и мне также хотелось бы узнать ответ на этот вопрос. Как вы думаете, предотвратит ли это создание еще одной миграции, которая изменяет атрибут ImageField.storage на ссылку settings.AVATAR_STORAGE?   -  person grantmcconnaughey    schedule 15.02.2016
comment
Привет, Грант, спасибо за посылку! Итак, вы бы добавили миграцию схемы в django-avatar и вручную отредактировали бы ее, чтобы получить что-то вроде storage=get_storage_class(settings.AVATAR_STORAGE)()? Я думаю, это может решить мою проблему, но вам нужно не забыть редактировать каждую будущую миграцию схемы django-avatar таким же образом. Кроме того, это может вызвать проблемы у людей, действительно пытающихся перейти с одного хранилища на другое, потому что это не приведет к замораживанию состояния во время миграции (возможно, - не уверен в этом).   -  person medmunds    schedule 15.02.2016
comment
Некоторые обсуждают миграции и хранилища в трекере Django (22373 и 22337), но не в контексте сторонних приложений. Интересно, поможет ли поднять этот вопрос там?   -  person medmunds    schedule 15.02.2016
comment
Да, это то, о чем я говорю. Я думаю, вы правы насчет того, что это не замораживает миграцию. Даже если я изменю его на использование AVATAR_STORAGE, это все равно не решит проблему изменения AVATAR_STORAGE в течение жизни проекта. Я действительно не знаю, как это сделать. Я постараюсь поднять проблему.   -  person grantmcconnaughey    schedule 16.02.2016

Ответы (1)


arrow_upward
1
arrow_downward

Ответ ... Попросите разработчиков django-avatar исправить это.

Если вы хотите просто использовать хранилище по умолчанию, вы должны передать None или django.core.files.storage.default_storage в ImageField. В этом случае storage kwarg не будет передано в поле при миграции.

Я создал PR, чтобы исправить это.

person Sergey Fedoseev    schedule 25.05.2016
comment
Красиво: default_storage - не знал об этом. Не будет ли django-avatar теперь нуждаться в новой миграции, чтобы переопределить явную ссылку на django.core.files.storage.FileSystemStorage() в его начальная миграция? - person medmunds; 26.05.2016
comment
@medmunds Я только что изменил существующую миграцию в PR, однако я не уверен, что это правильный подход / - person Sergey Fedoseev; 26.05.2016