Source field seems to be ignored on ModelField fields

[klloveall]

Hello!

I'll preface this with it's entirely possible I'm missing something, however, I can't see to get ModelField to work with specifying a source argument. From my reading of the docs, it seems like this should be supported but I've run in to many errors trying to make it work.

models.py:

class TaskResult(models.Model):
    ...

class UserBusinessTaskResult(models.Model):
    task = models.ForeignKey(TaskResult, ...)
    user_id = models.UUIDField(...)

serializers.py:

class UserBusinessTaskResultSerializer(serializers.ModelSerializer):
    task_name = serializers.ModelField(model_field=TaskResult()._meta.get_field('task_name'), read_only=True, source='task.task_name')
    task_kwargs = serializers.ModelField(model_field=TaskResult()._meta.get_field('task_kwargs'), read_only=True, source='task.task_kwargs')
    status = serializers.ModelField(model_field=TaskResult()._meta.get_field('status'), read_only=True, source='task.status')
    content_type = serializers.ModelField(model_field=TaskResult()._meta.get_field('content_type'), read_only=True, source='task.content_type')
    content_encoding = serializers.ModelField(model_field=TaskResult()._meta.get_field('content_encoding'), read_only=True, source='task.content_encoding')
    result = serializers.ModelField(model_field=TaskResult()._meta.get_field('result'), read_only=True, source='task.result')
    date_created = serializers.ModelField(model_field=TaskResult()._meta.get_field('date_created'), read_only=True, source='task.date_created')
    date_done = serializers.ModelField(model_field=TaskResult()._meta.get_field('date_done'), read_only=True, source='task.date_done')
    class Meta:
        model = UserBusinessTaskResult
        fields = [
            'user_id',
            'business_id',
            'task_id',
            'task_name',
            'task_kwargs',
            'status',
            'content_type',
            'content_encoding',
            'result',
            'date_created',
            'date_done',
        ]
        read_only_fields = [
            'user_id',
            'business_id',
        ]

Desired output from serializer:

{
    "user_id": "...",
    "task_id": "...",
    "task_name": "...",
    "task_kwargs": "...",
    "status": "...",
    "content_type": "...",
    "content_encoding": "...",
    "result": "...",
    "date_created": "...",
    "date_done": "..."
}

Current error:

AttributeError: 'UserBusinessTaskResult' object has no attribute 'task_name'

This tells me that the ModelField objects are ignoring the source argument I'm passing in to know where to source their data from (i.e. they're looking for it on the UserBusinessTaskResult object instead of the related TaskResult object).

At a higher level, the problem I have is I have a DB model (TaskResult) that is coming in from a library that I cannot edit but I have "extended" it with my own custom table that has a FK to the library table. I originally had this as just a nested-sterilizer which is fine, but as a user of the API, it is slightly weird to have to go into a separate dictionary to access some fields about the task but not all. I am aware this can be done with SerializerMethodFields as well, however that seems fairly inefficient and like a lot of boiler plate for something that feels like it should be easy/common-ish.

What I would really love is just a "RelatedModelField" or something like that that would let me do this:

class UserBusinessTaskResultSerializer(serializers.ModelSerializer):
    task_name = serializers.RelatedModelField('task.task_name')
    ...

I feel like this is a fairly common pattern I've run into a few times while using DRF and never come up with a great way to resolve it. Is there a feature somewhere that makes this easy that I've missed?

[browniebroke]

I've never defined serializer fields like this before serializers.ModelField(model_field=TaskResult()._meta.get_field('task_name'), ..., is there a reason why you're not using the appropriate serializer type directly? By that, I mean I would expect a CharField to be used:

class UserBusinessTaskResultSerializer(serializers.ModelSerializer):
    task_name = serializers.CharField(read_only=True, source='task.task_name')

    class Meta:
        model = UserBusinessTaskResult
        fields = [
            'user_id',
            'task_name',
        ]

Have you tried this? I'm assuming TaskResult is from django-celery-results?

[klloveall]

Yeah, that does generally work, I just dislike the duplication of information about what type of data is going though here.

It's a bit tedious in this case to go through and look up the definition and then map that to an appropriate DRF field when that mapping work has already been done. I'm not 100% sure on this, but I think it also looses (or you must copy over) various length and other restrictions too whereas just referencing the source DB field lets you pass all that data along. Finally, it looses or requires duplication of help text or other "metadata" type things that may be on the source field.

But stepping back from the specifics of my usecase here from a logical standpoint my brain says "this DRF field is actually just a front for this DB field" and I wish there was an easy way to represent that (fully) in code. Also, if I'm reading the documentation what I have above should work (even if it wasn't how things were intended) but as far as I can tell from reading through the relevant DRF field, the source argument wasn't used for ModelField fields.

[maziar-dandc]

overriding ModelField and setting the def get_attribute(self, instance): to be same as the Field class resolved this for me, definitely something I want DRF to provide out of the box.

[maziar-dandc]

uh, turns out ModelField is not 1-on-1 in terms of output with actual normal fields, I had a model File field that was returning relative paths in the DRF output using my overridden CustomModelField, turns out it doesn't use the to_representation of serializers.FileField and just returns return self.model_field.value_to_string(obj).

replacing CustomModelField with the good old FileField resolved the issue of relative paths, and made them absolute paths like everywhere else in my code, so I'm guessing the whole ModelField class needs better implementation.