Source code
from django.core.exceptions import FieldError, FullResultSet
from django.db.models.expressions import Col
from django.db.models.sql.compiler import SQLAggregateCompiler, SQLCompiler
from django.db.models.sql.compiler import SQLDeleteCompiler as BaseSQLDeleteCompiler
from django.db.models.sql.compiler import SQLInsertCompiler
from django.db.models.sql.compiler import SQLUpdateCompiler as BaseSQLUpdateCompiler
class SQLDeleteCompiler(BaseSQLDeleteCompiler):
def as_sql(self):
# Prefer the non-standard DELETE FROM syntax over the SQL generated by
# the SQLDeleteCompiler's default implementation when multiple tables
# are involved since MySQL/MariaDB will generate a more efficient query
# plan than when using a subquery.
where, having, qualify = self.query.where.split_having_qualify(
must_group_by=self.query.group_by is not None
)
if self.single_alias or having or qualify:
# DELETE FROM cannot be used when filtering against aggregates or
# window functions as it doesn't allow for GROUP BY/HAVING clauses
# and the subquery wrapping (necessary to emulate QUALIFY).
return super().as_sql()
result = ["DELETE %s FROM" % self.quote_name(self.query.get_initial_alias())]
from_sql, params = self.get_from_clause()
result.extend(from_sql)
try:
where_sql, where_params = self.compile(where)
except FullResultSet:
pass
else:
result.append("WHERE %s" % where_sql)
params.extend(where_params)
return " ".join(result), tuple(params)
Run 1
The code is moderately readable. Structure is logical with a clear single-method class. Nesting is shallow with only one try/except block, and action granularity is mostly one action per line. However, the intent is somewhat obscured by domain-specific Django/MySQL knowledge and a dense explanatory comment. Variable names like 'result' and 'params' are generic, and the mixed string formatting styles (%s and f-strings) slightly disrupt flow. The conditional logic requires understanding of SQL compiler internals, making it less accessible to non-specialists.
Run 2
The code has a clear purpose and includes an explanatory comment, which aids understanding. The logic is relatively straightforward without deep nesting. However, it relies on domain-specific knowledge of Django internals and SQL compiler behavior, making it less accessible to general readers. The mix of string formatting and list construction reduces clarity compared to f-strings or more explicit string building. The try/except/else structure is somewhat non-obvious, and the overall reading flow is interrupted by the conditional early return. While not unreadable, the code requires effort to parse due to implicit coupling with parent class behavior and intricate SQL generation logic.
Run 3
The code is generally readable with clear intent and good naming, but suffers from some issues. The class structure is logical, and the comment effectively explains why the custom implementation exists. Nesting is mostly flat, though the try/except/else adds slight complexity. The main weakness is the long docstring/comment combined with multiple conditional branches that could be broken down into smaller helper methods. Action granularity is mostly one action per line, but the list-building approach with `result` and `params` makes the flow slightly harder to follow. The reading flow is natural from top to bottom, but the mixed string formatting styles (`%s` vs f-strings) could be more consistent. Overall, it's above average but not excellent readability due to the dense logic and lack of separation between concerns.
Run 1
Code Structure: The method follows a logical sequence: check compatibility, fall back when necessary, build the DELETE statement, and return SQL with parameters. Nesting: Shallow control flow and an early return keep complexity low; the try/except/else is easy to follow. Clarity of intent: Descriptive names and comments clearly explain the MySQL/MariaDB optimization and its restrictions, though framework-specific concepts require Django knowledge. Code length: Concise for its purpose, with somewhat lengthy but useful explanatory comments; several imports are unused in this snippet. Action granularity: Statements generally perform one action per line, with readable multiline calls. Reading flow: Natural top-to-bottom progression, although the silent FullResultSet handler and exception-driven WHERE construction require some contextual understanding.
Run 2
Code Structure: The method is logically organized into eligibility checks, SQL construction, condition compilation, and return. Nesting: An early return keeps control flow shallow; the try/except/else adds only modest complexity. Clarity of intent: Descriptive names and comments explain both the optimization and its limitations, though Django compiler knowledge is needed to understand the details. Code length: The implementation is concise without sacrificing necessary explanation; several imports are unused in this snippet. Action granularity: Statements generally perform one clear action per line, with tuple unpacking appropriately grouping related results. Reading flow: Execution proceeds naturally from checking compatibility to assembling the query. The silent FullResultSet exception handling is slightly less intuitive without a brief explanation.
Run 3
Code Structure: A focused compiler override logically separates fallback handling, SQL construction, and return values. Nesting: Shallow control flow and an early return keep the main path flat; try/except/else is straightforward. Clarity of intent: Descriptive names and useful comments explain the database-specific optimization and its limitations, although Django compiler knowledge is needed to understand the details. Code length: Concise for its purpose, with proportionate explanatory comments; several imports are unused within the provided snippet. Action granularity: Statements generally perform one clear operation, with tuple unpacking appropriately grouping related results. Reading flow: Execution proceeds naturally from eligibility checks to query assembly and parameter collection. The silent FullResultSet exception handling is slightly less immediately obvious, and an additional blank line before the class would improve formatting.