wq.db Model Serializer
wq.db’s REST API leverages a custom ModelSerializer class that provides a number of enhancements to the ModelSerializer provided by Django REST Framework. This custom class is used by default in the default router. If you need to customize the serializer for a specific model, create a subclass of ModelSerializer and register it with the router:
# myapp/serializers.py
from wq.db.rest.serializers import ModelSerializer
class MySerializer(ModelSerializer):
# custom code ...
# myapp/rest.py
from wq.db import rest
from .models import MyModel
from .serializers import MySerializer
rest.router.register_model(
MyModel,
serializer=MySerializer,
fields="__all__", # Unless set on MySerializer.Meta
)
wq.db’s ModelSerializer provides a number of enhancements, mostly by overriding and adding to the default fields generated by Django REST Framework’s serializer. Since the primary goal is to facilitate @wq/app integration, the output is a bit more verbose than might be expected for a typical REST API.
In particular, every serialized object is rendered with a label property that corresponds to the string representation of the object (i.e. the result of the __str__ function). In addition, every foreign key will be rendered with both an identifier (e.g. parent_id) and a string representation (e.g. parent_label.). These properties are quite useful for rendering detailed list views without needing additional lookups to resolve foreign keys, but it can result in more database lookups by the server when the data is initially loaded. If performance is an issue, try overriding the queryset and using prefetch_related() or select_related() to join across foreign key relationships.
Other enhancements provided by wq.db’s ModelSerializer include:
- GeoJSON support for geometry fields (used in conjunction with wq.db’s
GeoJSONRenderer) - Support for custom “id” fields
- User-friendly datetime rendering (
[date]_label) - Automatic “nested” serializers for foreign keys when rendering detail views.