4 ms·

I am quite amazed this has to be done manually in Django. I work a lot with Symfony2 in PHP and that kind of Object serialization thing is pretty much built in.

by kayoone 12y ago

I am quite amazed this has to be done manually in Django. I work a lot with Symfony2 in PHP and that kind of Object serialization thing is pretty much built in. I just return my model from the controller and it gets serialized to JSON including child objects with pretty fine grained controls about what to serialize. Besides, after working a lot with REST webservices and AngularJS, i don't know if serializing child objects is really a good idea vs just getting the id and then using the api endpoint for the specific children separately. Having child objects serialized creates problems when doing PUT/UPDATE requests and you can also end up with fairly large sets of JSON. Of course doing dozens of requests instead (especially for lists) is also not the best of ideas, so i am not really sure how others handle this ?

norbert_mate 12y ago
In Django Rest Framework (DRF) you need serializer class. Maybe this is because DRF is not tightly coupled with the models from Django framework. As far as I know DRF does not support PUT/UPDATE operations for nested serializers. But there are cases when you just need to read. Like getting an activity feed which can't be modified directly by the users. I think if you have a good caching system it's better to return all the data for one request instead of creating new requests to get details about each entity.
andybak 12y ago
Django does this out of the box: https://docs.djangoproject.com/en/1.7/topics/serialization/ https://docs.djangoproject.com/en/1.7/topics/serialization/ But DRF adds lots of extra functionality. Even with DRF it's as simple as adding: class UserSerializer(serializers.ModelSerializer): class Meta: model = User to get full automatic serialization of a model. > I don't know if serializing child objects is really a good idea Depends on the specific case. For internal APIs I tend to create endpoints that give a view what it needs in a single request.
- norbert_mate 12y ago
  Correct. It's very easy to create a simple model serializer and this is what the general model serializer does. It's no big deal just saves a few line of code.
- whalesalad 12y ago
  You say "out of the box" but it's not that simple... 'blah blah DateTime is not JSON serializable'
  - andybak 12y ago
    Just tried it: from django.core import serializers print serializers.serialize("json", StockCount.objects.all()[:2]) >> [{"fields": {"timestamp": "1900-01-02T00:00:00Z", "version": 0, "item_instance": null, "item_model": 408, "stock_level": 999, "location": 2}, "model": "stocklevels.stockcount", "pk": 1}, {"fields": {"timestamp": "1900-01-02T00:00:00Z", "version": 0, "item_instance": null, "item_model": 409, "stock_level": 999, "location": 2}, "model": "stocklevels.stockcount", "pk": 2}]
numlocked 12y ago
We tend to load things (GET) in one large request that pulls a big hunks of JSON for everything certain parts of the app need. These have lots of nested serialization going on. We then have separate, traditional REST endpoints for updates/creates and incremental updates of the larger object.
adambratt 12y ago
No one has answered your question properly yet. This is an edge case for something called Django Content Types. It's basically a way to handle some sort of polymorphism in a table. Let's say you have a table called activity feed like in this example. Whether the items in the feed are images, blog posts, or status updates they're all going to have something in common and you'll have endpoints that should link any relevant tables and combine them. So you'd have an activity table and it would have a column for content_type and then content_object_id. Content type is basically just a reference to another DB table (blog or status update) with more info on this activity and content_object_id is the actual id of the row in that table. I've used Symfony, Laravel, and pretty much every other trendy PHP framework and nothing comes close to the ease of building APIs that is inherent in Django Rest Framework. This is just a very specific use case that you normally have to handle using it's own custom class. This just shows a way you can have DRF serialize it like a normal object without issue.
lazerscience 12y ago
There's not a general solution to serializing child objects, it totally depends on the use case and the number of children. So for example if you have a lot of child objects it might not even make sense to include theirs ids, but have a seperate (maybe nested) resource to retrieve them. On the other hand if there are only few children you might want to include them in their parent resource.

by kayoone 12y ago

norbert_mate 12y ago

In Django Rest Framework (DRF) you need serializer class. Maybe this is because DRF is not tightly coupled with the models from Django framework. As far as I know DRF does not support PUT/UPDATE operations for nested serializers. But there are cases when you just need to read. Like getting an activity feed which can't be modified directly by the users. I think if you have a good caching system it's better to return all the data for one request instead of creating new requests to get details about each entity.

andybak 12y ago

Django does this out of the box: https://docs.djangoproject.com/en/1.7/topics/serialization/ https://docs.djangoproject.com/en/1.7/topics/serialization/ But DRF adds lots of extra functionality. Even with DRF it's as simple as adding: class UserSerializer(serializers.ModelSerializer): class Meta: model = User to get full automatic serialization of a model. > I don't know if serializing child objects is really a good idea Depends on the specific case. For internal APIs I tend to create endpoints that give a view what it needs in a single request.

norbert_mate 12y ago
Correct. It's very easy to create a simple model serializer and this is what the general model serializer does. It's no big deal just saves a few line of code.
whalesalad 12y ago
You say "out of the box" but it's not that simple... 'blah blah DateTime is not JSON serializable'
- andybak 12y ago
  Just tried it: from django.core import serializers print serializers.serialize("json", StockCount.objects.all()[:2]) >> [{"fields": {"timestamp": "1900-01-02T00:00:00Z", "version": 0, "item_instance": null, "item_model": 408, "stock_level": 999, "location": 2}, "model": "stocklevels.stockcount", "pk": 1}, {"fields": {"timestamp": "1900-01-02T00:00:00Z", "version": 0, "item_instance": null, "item_model": 409, "stock_level": 999, "location": 2}, "model": "stocklevels.stockcount", "pk": 2}]

numlocked 12y ago

We tend to load things (GET) in one large request that pulls a big hunks of JSON for everything certain parts of the app need. These have lots of nested serialization going on. We then have separate, traditional REST endpoints for updates/creates and incremental updates of the larger object.

adambratt 12y ago

No one has answered your question properly yet. This is an edge case for something called Django Content Types. It's basically a way to handle some sort of polymorphism in a table. Let's say you have a table called activity feed like in this example. Whether the items in the feed are images, blog posts, or status updates they're all going to have something in common and you'll have endpoints that should link any relevant tables and combine them. So you'd have an activity table and it would have a column for content_type and then content_object_id. Content type is basically just a reference to another DB table (blog or status update) with more info on this activity and content_object_id is the actual id of the row in that table. I've used Symfony, Laravel, and pretty much every other trendy PHP framework and nothing comes close to the ease of building APIs that is inherent in Django Rest Framework. This is just a very specific use case that you normally have to handle using it's own custom class. This just shows a way you can have DRF serialize it like a normal object without issue.

lazerscience 12y ago

There's not a general solution to serializing child objects, it totally depends on the use case and the number of children. So for example if you have a lot of child objects it might not even make sense to include theirs ids, but have a seperate (maybe nested) resource to retrieve them. On the other hand if there are only few children you might want to include them in their parent resource.