Incorrect serializer used when querying relationship

[kopf]

Hi,

on 1.0.0-dev (826c9d49c3d4a95f04c4ababd2b89f2045e59eee), when querying a model that has a relationship, e.g. http://localhost:8888/api/v1/users/1/posts, and the users API has a specific serializer specified in its create_api call, this serializer will be used, even though we're requesting posts from the API, not users.

Apart from this, and one other issue, 1.0.0 looks very exciting indeed! Thanks for your hard work!

[jfinkels]

Yes, this issue was known to me, but it seemed a bit tricky to fix correctly. The issue is essentially wherever self.primary_serializer is called in the APIBase class (for example, https://github.com/jfinkels/flask-restless/blob/master/flask_restless/views/base.py#L1332). It should be delegating to the appropriate serializer for the particular model if the instance is of a different model, but instead it just serializes using the serializer for the primary model (i.e. the users model in your example).

[kopf]

I've forked and pushed a test for this on a branch in this commit: kopf@7d3cdfe

I'm having a go at tackling the problem, but am running into problems understanding the distinction between self.serializer, self.primary_serializer and self.serialize_relationship.

A solution I was thinking of was to store a look-up table somewhere, essentially a dict in the form {'model_name': serializer}, which would then be used when serializing objects. Is this a sensible approach?

[jfinkels]

@kopf wrote:

I'm having a go at tackling the problem, but am running into problems understanding the distinction between self.serializer, self.primary_serializer and self.serialize_relationship.

There are two kinds of things being serialized, one is resource objects (like when fetching /api/person/1), and one is resource identifier objects (like what appears under the relationships element in the resource object). I have two view classes, one for responding to requests for resource objects in views/resources.py, and one for responding to requests for resource identifier objects in views/relationships.py. Those two view classes have a common superclass, in views/base.py, which uses the subclass method use_resource_identifiers() to decide which serializer to use, the serializer for resource objects or the serializer for resource identifier objects. primary_serializer is the result of this decision.

A solution I was thinking of was to store a look-up table somewhere, essentially a dict in the form {'model_name': serializer}, which would then be used when serializing objects. Is this a sensible approach?

That's essentially what we do when using url_for, you might start by copying that code and create a serializer_for function. Check it out in helpers.py.

[jfinkels]

This should be fixed by pull request #493.