adrf's router binds async viewset CRUD to a-prefixed actions at runtime
(alist, acreate, aretrieve, aupdate, partial_aupdate, adestroy), so
self.action on an async viewset never matches the sync names.
Anything keyed by action name therefore needs its own copy of the mapping:
We maintain this dict in our projects:
ASYNC_TO_SYNC_ACTION = {
"alist": "list",
"acreate": "create",
"aretrieve": "retrieve",
"aupdate": "update",
"partial_aupdate": "partial_update",
"adestroy": "destroy",
}Proposal — either (or both):
- Export the mapping as a constant (e.g.
adrf.viewsets.ASYNC_TO_SYNC_ACTION), so
downstream code and schema generators share one source of truth with the router,
or
- Add a small property on the viewset, e.g.
resolved_action, returning the
sync-equivalent name.
The router already owns this knowledge (get_method_map); exporting it costs
nothing and removes a copy-paste constant from every integrating project. Happy to
send the PR if you're open to it — preference on shape?
adrf's router binds async viewset CRUD to
a-prefixed actions at runtime(
alist,acreate,aretrieve,aupdate,partial_aupdate,adestroy), soself.actionon an async viewset never matches the sync names.Anything keyed by action name therefore needs its own copy of the mapping:
action_serializers/ per-action permissions patterns),Support the adrf action "alist" when determining if a view is a listing view. tfranzel/drf-spectacular#1278),
We maintain this dict in our projects:
Proposal — either (or both):
adrf.viewsets.ASYNC_TO_SYNC_ACTION), sodownstream code and schema generators share one source of truth with the router,
or
resolved_action, returning thesync-equivalent name.
The router already owns this knowledge (
get_method_map); exporting it costsnothing and removes a copy-paste constant from every integrating project. Happy to
send the PR if you're open to it — preference on shape?