Post apiallocations
Body
Write-side serializer for provisioning a new Allocation.
is_default is intentionally not exposed — admins who want to
swap an owner's default use POST /api/allocations/{id}/default/
which atomically flips the partial unique constraint.
Optional parent_id creates a sub-Allocation carved from the named
parent. When supplied, repository_id is ignored (the view
inherits the parent's repository) and the caller must own the
parent directly. Thin-provisioning means no sum-check against the
parent's remaining headroom at creation — capacity is enforced at
upload time.
x >= 1x >= 1project- projectuser- userorganization- organization
project, user, organization 255Response
Resolve user.person once per serialization pass.
user.person memoizes per instance, but distinct users in a list are
distinct instances — so a list serializer would still issue one
Person query per row. When used many=True this mixin routes
through :class:_PersonReadThroughListSerializer, which calls
User.attach_persons to batch the whole page into a single query;
the per-render context cache below then dedups the name+email
double-read for each user.
The context cache lives only for the lifetime of the serializer tree,
so one .data render resolves each distinct user's Person at
most once and re-batches fresh on the next render.