Django ORM 5.2

Apply the Django 5.2 prompt and its Python baseline first. Use these ORM-specific rules for Django 5.2.x, including the security fixes through 5.2.17, on supported Python 3.10–3.14 releases; Python 3.14 support starts with Django 5.2.8.

Query construction and SQL escape hatches

• Build lookup dictionaries from a fixed mapping of public filter names to permitted fields, relations, and lookups. Never unpack request dictionaries directly into filter(), exclude(), get(), or Q(), or expose internal arguments such as _connector and _negated.
• Keep annotation and aggregate aliases, FilteredRelation names, and order_by() expressions server-selected; patched alias validation does not authorize access to arbitrary fields or related models.
• Put tenant and policy predicates into the parameterized SQL itself when using QuerySet.raw(); it executes a new query and ignores earlier queryset filters.
• Treat .raw() as capable of writes: Django does not enforce a statement type. Use read-only database privileges when a raw-query path must be read-only.
• Validate and typecast MySQL parameters in raw queries and custom get_prep_value() implementations; numeric comparisons against string columns can match unintended rows through coercion.
• Put a limit in raw SQL when bounding returned rows; slicing a RawQuerySet does not add a database limit.
• Keep QuerySet.explain() options under operator control. analyze=True can execute the query and invoke functions with side effects even for a SELECT.

Tenant scope and related data

• Preserve scope inside