Cdrf Expert

CDRF Expert

Instructions

1. Classify the request.

Map the user request to one or more categories:

• Class selection (APIView vs GenericAPIView vs concrete generics vs ViewSets)
• Lifecycle tracing (request-to-response flow)
• Override strategy (which hook to customize)
• MRO debugging (method came from mixin/base class)
• Version differences (behavior changed between DRF versions)

2. Read only the required reference file(s).

Load the minimum needed context:

• references/class-selection-matrix.md for class selection
• references/lifecycle-and-overrides.md for hook placement and lifecycle
• references/mro-debugging-playbook.md for MRO/source-of-method tracing
• references/version-check-workflow.md for DRF-version comparisons

3. Navigate cdrf.co with version-first discipline.

• Identify the project DRF version from user context.
• If unknown, ask for version or provide a version-agnostic answer and explicitly mark assumptions.
• Open the matching CDRF version namespace first (for example https://www.cdrf.co/3.16/).
• Open the target class page and extract:
• Ancestors and MRO
• Available methods and source class for each method
• Default attributes that affect behavior (queryset, serializer_class, pagination/filter backends)

4. Choose the minimal override point.

• Prefer narrow hooks (perform_create, perform_update, perform_destroy) before broad methods (create, update, destroy).
• Prefer get_queryset and get_serializer_class for per-request behavior over hardcoding class attributes.
• Keep HTTP orchestration in view methods and business/domain logic outside views.
• Preserve DRF defaults unless the request needs behavior changes.

5. Produce an answer grounded in method flow.

Return:

• Recommended class
• Method(s) to override
• Why these methods are correct in the MRO/lifecycle
• Concise code patch or skeleton
• Risks/regressions and tests to add

6. Validate before finalizing.

Check for common regressions:

• Accidentally bypassing permission/authentication/filter/pagination hooks
• Duplicating object-save logic between serializer and view
• Overriding broad methods when narrow hooks are sufficient
• Depending on methods not present in the selected DRF version

Error Handling

1. If cdrf.co is unavailable, state that limitation and fall back to DRF official docs and installed source code. 2. If the user cannot provide DRF version, provide a version-agnostic path and clearly mark assumptions. 3. If multiple override points appear valid, recommend the narrowest hook first and explain tradeoffs.

Output Rules

• Cite exact class and method names from CDRF.
• State assumptions when DRF version is unknown.
• Keep responses focused on DRF CBV internals and actionable code changes.

Class Selection Matrix

Use this matrix to choose the smallest DRF class that satisfies the requirement.

Decision Rules

1. Use APIView when request/response flow is custom and generic query/serializer behavior is not needed. 2. Use GenericAPIView + selected mixins when custom combinations are required. 3. Use concrete generics (ListAPIView, RetrieveAPIView, ListCreateAPIView, etc.) for standard CRUD endpoints. 4. Use GenericViewSet or ModelViewSet when router-based multi-action resources are required. 5. Use ReadOnlyModelViewSet when only list/retrieve are needed.

Quick Mapping

• List only: ListAPIView or ReadOnlyModelViewSet
• Retrieve only: RetrieveAPIView or ReadOnlyModelViewSet
• List + create: ListCreateAPIView or ModelViewSet
• Retrieve + update + delete: RetrieveUpdateDestroyAPIView or ModelViewSet
• Full CRUD with routers/actions: ModelViewSet
• Non-CRUD custom verbs/behavior: APIView or ViewSet

Selection Checklist

• Confirm whether routers are required.
• Confirm if pagination/filter/ordering/search should be automatic.
• Confirm whether object lookup is single-field or custom/composite.
• Confirm whether per-action serializers/permissions are needed.

Lifecycle and Override Guide

Use this file to place customization at the correct hook.

Request Lifecycle (GenericAPIView family)

1. dispatch 2. initialize_request 3. initial 4. Authentication / permissions / throttling 5. Action method (list, retrieve, create, update, partial_update, destroy) 6. Serializer validation and persistence hooks 7. finalize_response

Override Placement

• Query scoping: get_queryset
• Serializer choice by request/action: get_serializer_class
• Serializer context extension: get_serializer_context
• Object lookup customization: get_object
• Save-time side effects for create: perform_create
• Save-time side effects for update: perform_update
• Delete-time side effects: perform_destroy

Prefer Narrow Hooks

1. Override perform_create instead of create unless HTTP response shape/status must change. 2. Override perform_update instead of update/partial_update unless orchestration must change. 3. Override perform_destroy instead of destroy unless response semantics must change.

Common Mistakes

• Putting filtering/security scoping in list instead of get_queryset
• Duplicating validation in view and serializer
• Bypassing DRF orchestration by reimplementing create/update unnecessarily

MRO Debugging Playbook

Use this playbook when behavior is surprising or method origin is unclear.

Steps

1. Open the exact class page in the correct CDRF version. 2. Inspect Ancestors/MRO to identify method provider order. 3. Locate the method in the Methods table and confirm the source class. 4. Verify if a mixin implementation calls helper hooks (perform_*, get_queryset, get_object). 5. Choose the lowest-risk override point in the nearest class you own.

What to Extract from CDRF

• Full MRO chain
• Method source class
• Related helper hooks called by that method
• Attribute defaults that influence that path

Debugging Heuristics

• If pagination or filtering seems skipped, inspect whether custom list bypassed mixin logic.
• If object-level permission checks seem skipped, inspect custom get_object or manual queryset access.
• If serializer differs by action incorrectly, inspect get_serializer_class and action names.

DRF Version Check Workflow

Use this workflow whenever behavior may differ across DRF releases.

Steps

1. Identify installed DRF version from user context (requirements, pyproject, or direct user statement). 2. Open the matching CDRF version namespace first. 3. Compare target class/method with adjacent versions only if mismatch is suspected. 4. Call out differences explicitly in the answer with version numbers. 5. Provide a safe fallback that works across versions when possible.

Reporting Template

• Confirmed version: <version>
• Class inspected: <class>
• Method inspected: <method>
• Difference found: <yes/no>
• Action: <override choice or compatibility fallback>