Size: a a a

2021 May 11

Н

Нарул in Python KZ
источник

L

Leo in Python KZ
Я предположу, что так.
В этом случае, вы можете добавить класс LeadUserSerializer() (чтобы включались только те поля модели User, которые вам нужны (перечислите их в fields)
Затем, при описании LeadSerializer поле assigned_to = LeadUserSerializer()

в качестве атрибута класса queryset я рекомендую вам сделать Lead.objects.all().select_related('assigned_to') - это приведёт к тому, что запрос к БД будет включать JOIN, который позволит подгрузить нужные данные из таблицы user. В противном случае, для каждой записи будет отправляться отдельный запрос к таблице пользователей.
источник

Н

Нарул in Python KZ
В приложении lead такой view
источник

Н

Нарул in Python KZ
источник

L

Leo in Python KZ
вы уверены, что assigned_to должно быть только для чтения? Это поле не будет редактироваться посредством API?
источник

L

Leo in Python KZ
просто исходя из кода метода perform_update видно, что это поле должно обновляться.
источник

Н

Нарул in Python KZ
источник

Н

Нарул in Python KZ
закомментировал perform_update
источник

L

Leo in Python KZ
ииии, скорее всего наиболее органично будет, если вы сделаете так:
1) ReadLeadSerializer - сериализатор, который используется при отображении (действия list & retrieve)
2) LeadSerializer - остальные

в LeadViewSet вы определяете метод
def get_serializer_class(self):
   if self.action in ("list", "retrieve"):
       return ReadLeadSerializer
   return LeadSerializer


ReadLeadSerializer - можете его унаследовать от LeadSerializer, но в нём указать, что assigned_to = LeadUserSerializer()
В родительском классе - просто оставьте описание полей

в этом случае peform_update будет ненужным вообще
источник

Н

Нарул in Python KZ
источник

L

Leo in Python KZ
Рекомендации на будущее (уже неактуально для данного случая, но всё же):
Старайтесь не работать с request.data напрямую, уж если вы используете сериализаторы.
Учитывайте случаи, когда assigned_to отсутствует - request.data.get(), хотя это не лучшая идея - использование сериализаторов позволяет потом генерировать API документацию.
источник

L

Leo in Python KZ
Из этого скриншота неясно. Лучше покажите содержимое ответа сервера. Если там есть данные пользователя - то тогда дело во фронтенде.
источник

L

Leo in Python KZ
@narul310194 тут я смог всё понятно объяснить?
источник

Н

Нарул in Python KZ
источник

L

Leo in Python KZ
А ну значит пользователь не был назначен
источник

L

Leo in Python KZ
попробуйте не знаю, в БД поменять вручную на какой-нибудь ID пользователя и посмотреть, как выведется.
источник

Н

Нарул in Python KZ
Пробую понять
источник

Н

Нарул in Python KZ
источник

Н

Нарул in Python KZ
источник

L

Leo in Python KZ
В общем, при обновлении поля assigned_to мы хотим посылать ID пользователя, а вот при получении данных - объект с полями пользователя.
Поскольку структура в этих случаях разная - нам надо определить два разных сериализатора.
Но в то же время - структура эта похожа, поэтому вы определяете
class LeadSerializer(serializers.ModelSerializer):
    class Meta:
        model = User
        fields = [...]
        read_only_fields = [...]

затем уже наследуете от него
class ReadLeadSerializer(LeadSerializer):
    assigned_to = UserSerializer()
источник