Configuration validation breaks serializer inheritance

[gaffney]

Hey Tom,

We have quite a few base serializers that have their own methods and fields, etc., and serializer subclasses that use a subset of these fields declared in the parent.

This setup breaks after upgrading to 3.0 due to this particular configuration assertion:

ImproperlyConfigured: Field `blah_field` has been declared on serializer
`MySerializer`, but is missing from `Meta.fields`.

I do not see the point of this assertion, as inheritance worked as expected before, which allowed for cleaner and more extensible serializers. Do you remember why this was added?

Also, is there a clean way to work around this assertion? Currently I have a hack in the top-level serializer to work around this limitation, which makes this aspect of rest_framework to behave how it used to in 2.4:

class BaseSerializer(serializers.ModelSerializer):

  def get_fields(self):
    # hack; see rest_framework issue #2388
    declared_fields     = copy.deepcopy(self._declared_fields)
    meta_field_names    = getattr(self.Meta, 'fields', None)
    new_declared_fields = OrderedDict()

    for field_name in meta_field_names:
      if field_name not in declared_fields:
        continue
      new_declared_fields[field_name] = declared_fields[field_name]

    self._declared_fields = new_declared_fields

    return super(BaseSerializer, self).get_fields()

P.S. For reference, this validation addition was made in this commit: 87734be

[tomchristie]

why

Enforcing a single canonical style is a good thing - it's confusing and non-sensical to include a field on the serializer class but not include it in the fields list.

Having said that I don't think I'd really considered the inheritance case, so not sure how we'd best support that.

[gaffney]

Enforcing a single canonical style is a good thing

Yeah, I agree. But also the benefit of being able to use inheritance on serializers is pretty big, so it would be nice if there was a clean work-around so these features/characteristics could co-exist. When I have some spare cycles I will think about how this can be solved.

[tomchristie]

Added 3.0.4 milestone. We may or amy not actually hit that, but let's at least raise this one as a valid issue for any further 3.0.x releases.

[tomchristie]

it would be nice if there was a clean work-around so these features/characteristics could co-exist.

Agreed.

[gtaylor]

This is tripping us up currently, too. We have to end up making pretty extensive use of inheritance for some of our more complex endpoints.

[tomchristie]

Gotcha. Let's def try to make this happen for 3.0.4 then. Either store state that let's us determine if it's declare on the same class, or else otherwise infer it. Could prob check if the class above has any declared fields and remove those from the check if so. Failing test case pr would prob be a useful start (use Serializers not ModelSerializer there to keep the problem simple.)

[gaffney]

Awesomeness. I see the 3.0.4 milestone is at 100% -- is a release being made soon?

[tomchristie]

No blockers left, yeah.