Есть ли какое-то преимущество в использовании декоратора для моделей содержащих ImageField?

Question

[Mikkkch]

Здравствуйте, у некоторых в коде часто наблюдаю что-то вроде:

def contain_photos(model):
    upload_path = model.__name__.lower() + 's'
    image_field = models.ImageField(upload_to=upload_path)
    setattr(model, 'photo', image_field)


@contain_photos
class Animal(models.Model):
    pass

Есть ли смысл у себя делать что-то вроде этого? Или просто просто в каждую модель вносить поле ImageField у устанавливать соответствующий путь для сгрузки изображений?

Comments

[Ilya Chichak]

1) изучите, как работают декораторы (спойлер: не так)
2) изучите, что такое наследование в ООП
3) изучите, как работает наследование моделей в Django

[Mikkkch]

Ilya Chichak, забавный комментарий от человека, который явно даже в исходники используемых технологий не заходит.

[Ilya Chichak]

Mikkkch,



сами то этот код пробовали?

1) декоратор должен что-то вернуть. у вас он этого не делает
сделать его, как минимум

def contain_photos(model):
    upload_path = model.__name__.lower() + 's'
    image_field = models.ImageField(upload_to=upload_path)
    setattr(model, 'photo', image_field)
    return model

это будет работать, но только в рантайме

2) в миграции это поле не будет отображено, т.к. изменения моделей собираются статически

[Mikkkch]

Ilya Chichak, конечно же не использовал, раз обратился с этим псевдокодом сюда. В первой строчке вопроса речь идет о том, что видел что-то подобное в исходниках и так не разобрался для чего это. Но речь не об этом идет, а о том, с какой целью был написан комментарий под моим вопросом, в котором раздавались советы касательно того, что стоит изучить

[Ilya Chichak]

Mikkkch, Извините, не хотел задеть

Мне кажется подобный декоратор был использован чтобы динамически задать место для сохранения файлов. И применялся он к моделям, в которых это поле уже есть. В рантайме оно переопределялось полем, в котором upload_to указывает на место исходя из названия модели.

поскольку при наследовании сложно привязаться к классу модели-наследника

Если вы укажете модуль, в котором это встретилось - постараюсь ответить более точно

И сдается мне, что это было сделано для унификации.
Если вернуться к вопросу, есть ли смысл - мне кажется, если у вас много моделей с одинаковой логикой работы с изображениями - почему нет. Но если таких моделей всего пара, я бы работал с каждым таким полем отдельно. Плюс, можно более точно задать их поведение. Возможно, постобработку какую-то, или динамическое место сохранения (по пользователю, времени или ещё как-то)

[Mikkkch]

Ilya Chichak, да, после того, как вы скинули мне скрины и сказали, что поле, применяющееся при использовании декоратора не употребляется при миграциях и соответственно в базе, я тоже пришел к такому выводу.

в самом начале мне вообще показалось, что это используется с целью не прописывать в каждой модели одно и то же поле, содержащее путь, соответствующий названию класса.