Dexy Dexy / Explore / Django 6 PR Review
Sign in

Django 6 PR Review

Guidelines for reviewing Django pull requests with a focus on Async ORM, Service Layer architecture, and database safety.

· 0 runs

About this playbook

Purpose

To ensure Django pull requests adhere to modern (v6+) standards, prioritizing asynchronous performance, clean business logic separation, and database integrity.

Prerequisites

  • Access to the GitHub Pull Request.
  • Understanding of the project's database schema and migration history.

Steps · 7

1 Step 1 – Initial Context & Logic Review

Input: pr_context
Output: logic_notes
Gate: none
On error: abort

  • Read the PR description and understand the feature/bug.
  • Identify the models, views, and serializers/forms affected.
2 Step 2 – Async Correctness (Django 6.0+)

Input: view_code, orm_queries
Output: async_findings
Gate: none
On error: continue

  • Verify that high-concurrency views and ORM queries are using async where appropriate.
  • Ensure no blocking calls are made inside async views.
3 Step 3 – Service Layer & Business Logic

Input: model_code, business_logic
Output: architecture_findings
Gate: none
On error: continue

  • Check for "Fat Models" or logic-heavy Views.
  • Suggest moving complex business logic into dedicated services.py or similar modules.
4 Step 4 – Database & ORM Safety

Input: migrations, querysets
Output: db_findings
Gate: none
On error: continue

  • Check for N+1 queries; verify select_related and prefetch_related usage.
  • Review migrations for safety (e.g., adding indexes, data migrations).
  • Leverage db_default and GeneratedField where database-level logic is safer.
5 Step 5 – Security & Permissions

Input: auth_code, views
Output: security_findings
Gate: none
On error: continue

  • Verify authentication and object-level permissions (PermissionRequiredMixin or custom logic).
  • Ensure safe handling of user input (avoid raw SQL, proper escaping in templates).
  • Check for CSRF protection and secure file handling.
6 Step 6 – Logging & Observability

Input: logging_calls
Output: observability_findings
Gate: none
On error: continue

  • Ensure Structured Logging is used instead of basic print or string-based logs.
  • Verify that critical errors and transitions are logged with sufficient context.
7 Step 7 – Test Coverage & Severity Findings

Input: tests, all_findings
Output: review_report
Gate: none
On error: abort

  • Verify the PR adds unit tests for services and integration tests for APIs/Views.
  • Output findings by severity (P0-P3).