Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.


See original GitHub issue

DRF will not auto generate a Serializer for an Abstract class. What do you think about adding a AbstractModelSerializer? This is my first pass of an implementation:

class AbstractModelSerializer(serializers.ModelSerializer):
    def get_fields(self):
        Return the dict of field names -> field instances that should be
        used for `self.fields` when instantiating the serializer.
        assert hasattr(self, 'Meta'), (
            'Class {serializer_class} missing "Meta" attribute'.format(
        assert hasattr(self.Meta, 'model'), (
            'Class {serializer_class} missing "Meta.model" attribute'.format(

        declared_fields = copy.deepcopy(self._declared_fields)
        model = getattr(self.Meta, 'model')
        depth = getattr(self.Meta, 'depth', 0)

        if depth is not None:
            assert depth >= 0, "'depth' may not be negative."
            assert depth <= 10, "'depth' may not be greater than 10."

        # Retrieve metadata about fields & relationships on the model class.
        info = get_field_info(model)
        field_names = self.get_field_names(declared_fields, info)

        # Determine any extra field arguments and hidden fields that
        # should be included
        extra_kwargs = self.get_extra_kwargs()
        extra_kwargs, hidden_fields = self.get_uniqueness_extra_kwargs(
            field_names, declared_fields, extra_kwargs

        # Determine the fields that should be included on the serializer.
        fields = OrderedDict()
        for field_name in field_names:
            # If the field is explicitly declared on the class then use that.
            if field_name in declared_fields:
                fields[field_name] = declared_fields[field_name]

            # Determine the serializer field class and keyword arguments.
            field_class, field_kwargs = self.build_field(
                field_name, info, model, depth

            # Include any kwargs defined in `Meta.extra_kwargs`
            extra_field_kwargs = extra_kwargs.get(field_name, {})
            field_kwargs = self.include_extra_kwargs(
                field_kwargs, extra_field_kwargs

            # Create the serializer field.
            fields[field_name] = field_class(**field_kwargs)

        # Add in any hidden fields.

        return fields

    def get_unique_together_validators(self):
        return []

    def get_unique_for_date_validators(self):
        return []

    def get_default_field_names(self, declared_fields, model_info):
        Return the default list of field names that will be used if the
        `Meta.fields` option is not specified.
        return (
            list(declared_fields.keys()) +
            list(model_info.fields.keys()) +

def get_field_info(model):
    Given a model class, returns a `FieldInfo` instance, which is a
    `namedtuple`, containing metadata about the various field types on the model
    including information about their relationships.
    opts = model._meta.concrete_model._meta

    pk = None
    fields = _get_fields(opts)
    forward_relations = _get_forward_relationships(opts)
    reverse_relations = _get_reverse_relationships(opts)
    fields_and_pk = fields
    relationships = _merge_relationships(forward_relations, reverse_relations)

    return FieldInfo(pk, fields, forward_relations, reverse_relations,
                     fields_and_pk, relationships)

Issue Analytics

  • State:open
  • Created 8 years ago
  • Reactions:1
  • Comments:5

github_iconTop GitHub Comments

w121211commented, Apr 8, 2016

+1 Some cases I need to manipulate temporary data but not really go into the database. Use an abstract model to represent these data improve the readability and consistency as a Django app. It will be helpful if I don’t need to declare the data structure again in a serializer.

tOloruncommented, Aug 2, 2018

Does this code still work?

Read more comments on GitHub >

github_iconTop Results From Across the Web

django rest framework abstract class serializer - Stack Overflow
Setting abstract = True on the TypeBaseSerializer because there is no such thing as a abstract serializer. Correct me if I am wrong....
Read more >
Serializers - Django REST framework
We provide a Serializer class which gives you a powerful, generic way to control the output of your responses, as well as a...
Read more >
Raise error when ModelSerializer used with abstract model.
An abstract model is just a Python class for sharing code with other models, it's not actually a model, so here you're referencing...
Read more >
django rest framework abstract class serializer - YouTube
Django : django rest framework abstract class serializer [ Beautify Your Computer : ] Django ...
Read more >
Generic ViewSets for abstract base classes in Django Rest ...
Abstract base classes are useful when you want to put some common information into a number of other models. You write your base...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found