Могу ли я повторно использовать экземпляр output_field в Django ORM, или мне всегда следует создавать дубликат?

У меня есть кодовая база на Django, которая выполняет много функций ORM Case/When/ExpressionWrapper/Coalesce/Cast, и некоторые из них иногда требуют поле в качестве аргумента – output_field.

from django.db.models import FloatField, F
some_param1=Sum(F('one_value')*F('second_value'), output_field=FloatField())
some_param2=Sum(F('one_value')*F('second_value'), output_field=FloatField())
some_param3=Sum(F('one_value')*F('second_value'), output_field=FloatField())
some_param4=Sum(F('one_value')*F('second_value'), output_field=FloatField())
some_param5=Sum(F('one_value')*F('second_value'), output_field=FloatField())

Иногда я задумываюсь, почему я всегда создаю один и тот же экземпляр любого подкласса Field снова и снова. Есть ли какая-то разница, если я просто передам один экземпляр и разделю его между выражениями? Например:

from django.db.models import FloatField, F

float_field = FloatField()

some_param1=Sum(F('one_value')*F('second_value'), output_field=float_field)
some_param2=Sum(F('one_value')*F('second_value'), output_field=float_field)
some_param3=Sum(F('one_value')*F('second_value'), output_field=float_field)
some_param4=Sum(F('one_value')*F('second_value'), output_field=float_field)
some_param5=Sum(F('one_value')*F('second_value'), output_field=float_field)

Я не смог найти это в документации, и исходный код плохо документирован в отношении этого параметра.

П.С. Пример вымышленный, просто представьте собой большую функцию аннотирования, которая выполняет много обработки с использованием Case/When/ExpressionWrapper/Coalesce/Cast и имеет много дублирующихся экземпляров Field в качестве output_field.

Вы можете повторно использовать поле. Использование этого output_field=… ^[Django-doc] служит двум целям:

1. тип иногда требует специального форматирования, обычно для GIS колонок, так как точка, полигоны и т.д. должны быть преобразованы в текст, чтобы Django мог их понять; и
2. чтобы знать, какие преобразования и фильтры могут быть применены к нему.

Действительно, если мы используем:

queryset = queryset.annotate(
    some_param1=Sum(
        F('one_value') * F('second_value'), output_field=CharField()
    )
)

то Django предположит, что some_param1 является CharField (здесь это не имеет большого смысла), и таким образом вы можете использовать:

queryset.filter(some_param1__lower='a')

поскольку __lower определен как фильтр для CharField. Но для FloatField это не имеет большого смысла.

Но поле не специализировано и не изменено. Это больше похоже на “сигнальный” объект для указания, что с ним можно сделать.

Тем не менее, я не вижу много причин для преобразования кода с целью предотвратить создание FloatField. Если мы используем %timeit, мы получаем:

In [1]: %timeit FloatField()
3.82 µs ± 379 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops each)

Таким образом, создание занимает примерно 3.82 микросекунды. Обычно представление имеет гораздо больше работы, чем это, поэтому написание более эффективного запроса или сохранение раундтрип до базы данных (очень) вероятно превзойдет любую оптимизацию, связанную с сохранением FloatField на несколько порядков.