Fix circular references in all API resources.
Review Request #7654 — Created Sept. 21, 2015 and submitted
Once upon a time, I had fixed circular references in the API serialization.
This regressed with the introduction of field limiting.The core problem was that for foreign key and queryset types, we'd just
serialize that field as the list of objects, rather than recursing and asking
each of those to serialize themselves using the current state. Since the list
of expanded fields will always be the same when the encoder tried to serialize
using the global state, we'd hit the circular reference.By asking each of those objects to serialize themselves with the limited list
of expanded fields, we'll only recurse once for each type.
- Set up two review requests which depended on each other. Saw that I could
make changes to their drafts. - Added a new unit test and fixed existing unit tests to test the correct
behavior.
Description | From | Last Updated |
---|---|---|
QuerySets are always going to return the same object, so we should pre-fetch the right serializer before processing the list … |
chipx86 | |
list comprehension redefines 'obj' from line 724 |
reviewbot | |
The formatting is kinda weird here. Can we wrap some arguments to the next line instead? Actually, since we're repeating … |
chipx86 | |
Col: 80 E501 line too long (84 > 79 characters) |
reviewbot | |
Col: 80 E501 line too long (80 > 79 characters) |
reviewbot | |
Col: 80 E501 line too long (84 > 79 characters) |
reviewbot | |
Col: 80 E501 line too long (80 > 79 characters) |
reviewbot |
-
I'm missing something about how this solves the problem. Aren't we sharing the same request and other state, containing all the expand information? How does it not continue to expand indefinitely?
-
QuerySets are always going to return the same object, so we should pre-fetch the right serializer before processing the list (probably based on the first item, if not an empty list). That'll help make this less expensive.
-
The formatting is kinda weird here. Can we wrap some arguments to the next line instead?
Actually, since we're repeating the same queryset serialization logic as before, let's move this into a
_serialize_queryset
utility function.