Django REST Framework: Dynamic Fields in Serializers

Post author By masnun
Post date October 21, 2015
7 Comments on Django REST Framework: Dynamic Fields in Serializers

Here’s the use case, I need to add some extra fields to my serializer depending on a request. For example, if the query string contains “extra=true”, then add the extra fields. Luckily, serializers get a “context” argument when they are initialized. We can use this to customize our serializers as needed.

The fields defined on a serializer are available in a instance variable named “fields”. So we can add/delete/edit fields from it. Let’s see an example:

class OrderSerializer(ModelSerializer):
    payments = PaymentSerializer(many=True, read_only=True)
    evaluations = OrderEvaluationSerializer(many=True, read_only=True)

    def __init__(self, *args, **kwargs):
        super(OrderSerializer, self).__init__(*args, **kwargs)

        request = kwargs['context']['request']
        include_address = request.GET.get('include_address', False)

        if include_address:
            self.fields['user_location'] = UserLocationSerializer(read_only=True)

class OrderSerializer(ModelSerializer):

payments = PaymentSerializer(many=True, read_only=True)

evaluations = OrderEvaluationSerializer(many=True, read_only=True)

def __init__(self, *args, **kwargs):

super(OrderSerializer, self).__init__(*args, **kwargs)

request = kwargs['context']['request']

include_address = request.GET.get('include_address', False)

if include_address:

self.fields['user_location'] = UserLocationSerializer(read_only=True)

Please note, here we have used another serializer (UserLocationSerializer) from inside our main serializer. The second one is being initialized by us. So it would not get the context. If we need to do something down there as well, then we need to pass it ourselves.

class OrderSerializer(ModelSerializer):
    payments = PaymentSerializer(many=True, read_only=True)
    evaluations = OrderEvaluationSerializer(many=True, read_only=True)

    def __init__(self, *args, **kwargs):
        super(OrderSerializer, self).__init__(*args, **kwargs)

        request = kwargs['context']['request']
        include_address = request.GET.get('include_address', False)

        if include_address:
            self.fields['user_location'] = UserLocationSerializer(read_only=True, context=kwargs['context'])

class OrderSerializer(ModelSerializer):

payments = PaymentSerializer(many=True, read_only=True)

evaluations = OrderEvaluationSerializer(many=True, read_only=True)

def __init__(self, *args, **kwargs):

super(OrderSerializer, self).__init__(*args, **kwargs)

request = kwargs['context']['request']

include_address = request.GET.get('include_address', False)

if include_address:

self.fields['user_location'] = UserLocationSerializer(read_only=True, context=kwargs['context'])

Now the second serializer will get the request too and we can use the same way to customize it!

7 replies on “Django REST Framework: Dynamic Fields in Serializers”

Thanks for this concise clear example

Fantastic! Thank you 🙂

No longer the recommended way.

The recommended way is

<span class="k">class</span> <span class="n">AuthorSerializer</span>(<span class="n">serializers</span>.<span class="n">ModelSerializer</span>):
    <span class="n">age</span> = <span class="n">serializers</span>.<span class="n">SerializerMethodField</span>()

    <span class="k">class</span> <span class="n">Meta:</span>
        <span class="n">model</span> = <span class="n">Author</span>
        <span class="n">fields</span> = <span class="s">'__all__'</span>

    <span class="n">def</span> <span class="n">get_age</span>(<span class="k">self</span>, <span class="n">instance</span>):
        <span class="k">return</span> <span class="n">datetime</span>.<span class="n">datetime</span>.<span class="n">now</span>().<span class="n">year</span> - <span class="n">instance</span>.<span class="n">dob</span>.<span class="n">year</span>

class AuthorSerializer(serializers.ModelSerializer):

age = serializers.SerializerMethodField()

class Meta:

model = Author

fields = '__all__'

def get_age(self, instance):

return datetime.datetime.now().year - instance.dob.year

I think you misunderstood the purpose. The field is added based on whether a certain GET parameter is passed or not. SerializerMethodField is always available.

I’m having an issue where the context is not available to the __init__ if the serializer is a nested serializer:

Do you know how to forward the context along?

the following code yields this error:
reque st = kwargs[‘context’][‘request’]
KeyError: ‘context’

class PlaylistSerializer(serializers.ModelSerializer):
    id = serializers.ReadOnlyField()
    songs = SongSerializer(many=True, read_only=True)

class PlaylistSerializer(serializers.ModelSerializer):

id = serializers.ReadOnlyField()

songs = SongSerializer(many=True, read_only=True)

class SongSerializer(serializers.ModelSerializer):
    id = serializers.ReadOnlyField()
    catalog_number = serializers.CharField(max_length=4000)
    
    def __init__(self, *args, **kwargs):
        super(SongSerializer, self).__init__(*args, **kwargs)
        request = kwargs['context']['request']

class SongSerializer(serializers.ModelSerializer):

id = serializers.ReadOnlyField()

catalog_number = serializers.CharField(max_length=4000)

def __init__(self, *args, **kwargs):

super(SongSerializer, self).__init__(*args, **kwargs)

request = kwargs['context']['request']

Exactly what I needed!

This is not the canonical way to do this; you are meant to define different serializer classes for every case, and then utilize get_serializer_class in the viewset for your conditional logic. If it was meant to be done the way you describe, it would have been easy enough for the drf team to include a canonical way for you to perform this task from within the serializer.

You may feel it’s heavy-handed to define a serializer class for every layer of granularity you want to include in your response, but I would counter such a sentiment by asking; why is your API spec so inconsistent? Why should a consumer of your API need to deal with so many small variations in your responses? If some fields are computationally expensive to generate, perhaps you would be better served by making this it’s own endpoint altogether? If they aren’t, why not simply include them in every response?

I cannot fathom a convincing use-case for this pattern.

Comments are closed.

Recent Posts

Recent Comments

Archives

Categories