Skip to content

FlexFieldsWriteableNestedSerializerMixin

Overview

This is a utility mixin making a single class that makes serializers flex & nested writable.

_expand_fields_for_write

Swap each ?e= relation for its nested serializer, the expand half of apply_flex_fields, without its sparse-fieldset removal -- a write validates every field regardless of ?f=/?om=, so removal has no place on this path. Nested ?f=/?om= selectors for the expanded relation (e.g. f=employee.name) are not passed down either, for the same reason: they must not narrow the nested serializer's own validation. to_representation re-swaps the relation with a fresh nested serializer that does carry them, for the response.

Signature

_expand_fields_for_write(self, fields, flex_options)

Parameters

NameTypeRequiredDescription
selfyes
fieldsyes
flex_optionsyes

Source

server/vueda/core/serializers/__init__.py:219

_extract_relations

Signature

_extract_relations(self, validated_data)

Parameters

NameTypeRequiredDescription
selfyes
validated_datayes

Source

server/vueda/core/serializers/__init__.py:240

apply_flex_fields

Signature

apply_flex_fields(self, fields, flex_options)

Parameters

NameTypeRequiredDescription
selfyes
fieldsyes
flex_optionsyes

Source

server/vueda/core/serializers/__init__.py:147

to_internal_value

?e= (expand) names relations whose payload is a nested object rather than a flat PK, so each expanded relation is swapped for its nested serializer here, before deserialization, to accept that shape. See the nested-writable-inlines guide for the query-param contract; this half of flex-field handling is independent of sparse-fieldset narrowing and stays on the write path.

?f=/?om= are not applied here. They narrow the representation only, in to_representation (via ensure_flex_fields_applied), so a required field they exclude still fails validation instead of silently losing its validator. Deserialization must not call ensure_flex_fields_applied for this reason: that helper runs the full apply_flex_fields, sparse-fieldset removal included, which is exactly what would drop the validator.

Signature

to_internal_value(self, data)

Parameters

NameTypeRequiredDescription
selfyes
datayes

Source

server/vueda/core/serializers/__init__.py:192

to_representation

?f=/?om= (_flex_options_rep_only, sourced from query params) narrow the representation only. Applying them here, rather than in to_internal_value, keeps a write validating against the serializer's full field set while still narrowing the response a write returns, since to_representation runs after save().

fields=/omit= passed as serializer kwargs (_flex_options_base) are a different entry point: get_fields() applies them before either to_internal_value or to_representation runs, so they narrow validation and representation alike. That is unchanged and deliberate -- a caller constructing a serializer with explicit kwargs is opting in to restricting both directions, unlike a client shaping a response with a query parameter.

Delegates the view-bound check and the actual application to ensure_flex_fields_applied, the same helper a caller like VuedaViewSet.get_queryset uses to resolve .fields before an instance is ever serialized (for prefetch planning). Both call sites must agree on when application is safe and on the _flex_fields_rep_applied double-application guard, so that logic lives in one place rather than two copies that could drift.

Signature

to_representation(self, instance)

Parameters

NameTypeRequiredDescription
selfyes
instanceyes

Source

server/vueda/core/serializers/__init__.py:167

update

Signature

update(self, instance, validated_data)

Parameters

NameTypeRequiredDescription
selfyes
instanceyes
validated_datayes

Source

server/vueda/core/serializers/__init__.py:251

update_or_create_direct_relations

Signature

update_or_create_direct_relations(self, attrs, relations)

Parameters

NameTypeRequiredDescription
selfyes
attrsyes
relationsyes

Source

server/vueda/core/serializers/__init__.py:237

_declared_fields

Source

server/vueda/core/serializers/__init__.py:137

Documents matching: server v3.0.0a1.post1client v3.0.0-alpha.2