tn
Ещё документировать код неплохо и спецификацию писать
Size: a a a
2020 January 18
ℕ
Зато удобно
при чтении - да. Но я начинал с питона. Поэтому не особо фанат статической типизации
PZ
ℕo ℕame
при чтении - да. Но я начинал с питона. Поэтому не особо фанат статической типизации
код пишется один раз, а читается - много, поэтому лучше будет удобнее читать, чем писать.
AG
Народ поделитесь мнением: где бы вы агрегировали данные из нескольких таблиц, чтобы прогнать итог через DRF-сериализаторы и отдать на фронт через DRF-view?
Для формирования графика.
Отдельные классы, в DRF-сериализаторах или, может, в DRF-view?
Для формирования графика.
Отдельные классы, в DRF-сериализаторах или, может, в DRF-view?
A
Народ поделитесь мнением: где бы вы агрегировали данные из нескольких таблиц, чтобы прогнать итог через DRF-сериализаторы и отдать на фронт через DRF-view?
Для формирования графика.
Отдельные классы, в DRF-сериализаторах или, может, в DRF-view?
Для формирования графика.
Отдельные классы, в DRF-сериализаторах или, может, в DRF-view?
Я за отдельные классы
A
S – single responsibility
AG
Я за отдельные классы
спасибо, 👍
AG
по желанию начальства, мне пришлось делать в сериализаторах((
A
A
странное, что начальство в такие вещи вмешивается)
DT
по желанию начальства, мне пришлось делать в сериализаторах((
ну если модели связаны, почему нет ?
достаточно обычная практика
достаточно обычная практика
AG
ну если модели связаны, почему нет ?
достаточно обычная практика
достаточно обычная практика
да, модели связаны:
все инвойсы за период, разбитые по статусам +
все инвойсы за период, разбитые по статусам +
OneToMany модели для подсчета суммPZ
в сериализаторе не всегда есть доступ к кверисету, select_related\prefetch_related присунуть некуда.
AG
в сериализаторе не всегда есть доступ к кверисету, select_related\prefetch_related присунуть некуда.
прокинул
далее уже этот
request в главный сериализатор и в нем уже сформировал queryset с prefetch_relatedдалее уже этот
queryset прокидывал дочерним сериализаторам, в которых нужно извлечь данныеPZ
прокинул
далее уже этот
request в главный сериализатор и в нем уже сформировал queryset с prefetch_relatedдалее уже этот
queryset прокидывал дочерним сериализаторам, в которых нужно извлечь данныеКстати, request уже есть в контексте, а дочерние сериализаторы (прописанные в филдах) имеют доступ к контексту парента.
b
ребят подскажите, есть модели, описал классы для серилизациии https://dpaste.org/4r4i
пытаюсь получить данные:
получаю ошибку:
где я накосячил ?
пытаюсь получить данные:
settings = ABSettings.objects.filter(user=user).values(*items)
user_data = ABSettingsSerializer(settings)
print(user_data.data)
получаю ошибку:
AttributeError: Got AttributeError when attempting to get a value for field `attribute` on serializer `ABSettingsSerializer`.
The serializer field might be named incorrectly and not match any attribute or key on the `QuerySet` instance.
где я накосячил ?
AG
Кстати, request уже есть в контексте, а дочерние сериализаторы (прописанные в филдах) имеют доступ к контексту парента.
я строил вьюху на
Пока писал ответ, подумал что я мог бы сделать главным сериализатор
rest_framework.views.APIView и сериализовывал в методе get()Пока писал ответ, подумал что я мог бы сделать главным сериализатор
serializers.ListSerializer и вьюху ListAPIViw )PZ
я строил вьюху на
Пока писал ответ, подумал что я мог бы сделать главным сериализатор
rest_framework.views.APIView и сериализовывал в методе get()Пока писал ответ, подумал что я мог бы сделать главным сериализатор
serializers.ListSerializer и вьюху ListAPIViw )ну просто я хотел напомнить, что контексты - прикольная штука. Чтобы руками ничего никуда не протакивать.
iS
чтобы у объекта вытащить поле name, надо писать
```
object.__getattribute__('name')?
```
```
object.__getattribute__('name')?
```
AG
чтобы у объекта вытащить поле name, надо писать
```
object.__getattribute__('name')?
```
```
object.__getattribute__('name')?
```
getattr(object, 'name', None)