Django ORM 6.0

Apply the Django 6.0 prompt first. These additional rules cover Django ORM 6.0.8 on Python 3.12–3.14, including query scope, related objects, write paths, constraints, transactions, database routing, and migrations. Apply them to synchronous and asynchronous ORM entry points.

Query construction and projections

• Map external filter, sort, projection, relation, and aggregation choices to fixed field paths, lookup operators, expressions, and aliases. Never expand request dictionaries directly into Q(), filter(), annotate(), or alias(); parameterized values do not authorize access through arbitrary lookup paths.
• Keep custom Lookup.as_sql() and expression as_sql() implementations parameterized: compile child expressions with the supplied compiler and return SQL plus a tuple of parameters, as required by Django 6.0. Do not interpolate child values into SQL to work around parameter-list incompatibilities.
• Put tenant and permission predicates inside each raw statement, including SQL passed to raw() on a previously filtered QuerySet; raw() starts a new query and discards that filtering. Review raw subqueries for their own scope.
• Bound raw-query results in SQL; slicing or indexing a RawQuerySet does not add a database-level limit. On MySQL, validate parameter types before raw comparisons because implicit numeric coercion can change which text values match.
• Use explicit approved fields for values() and response serialization. Treat only() and defer() as loading optimizations: accessing an omitted model field can fetch it later, so neither API