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 has a clear purpose and handles a specific edge case with a helpful comment. However, readability is undermined by inconsistent formatting (e.g., misaligned continuation on the first line of the `split_having_qualify` call), which creates visual clutter. Nesting is minimal, and the reading flow is mostly logical, but the long `if` condition and dense SQL-related string formatting reduce clarity. Action granularity is mostly one action per line, though the initial call formatting is confusing. The code is concise overall but the tangled first statement and lack of consistent indentation make it harder to parse than necessary. Improving line breaks and aligning parameters would significantly enhance readability.
Run 2
The code has a logical structure and clear purpose, but several readability issues reduce its score. The main problems are: (1) inconsistent indentation in the `split_having_qualify` call, making the argument continuation visually confusing; (2) multi-line method call formatting lacks clear visual separation between arguments; (3) the inline comments are helpful but the comment block is lengthy relative to the code; (4) variable reuse of `params` from `from_sql` before being extended by `where_params` creates ambiguity about its origin. Positive aspects: flat nesting (only one level for the try/except and if/else), one action per line in most cases, and clear naming. The reading flow is somewhat disrupted by the formatting issue and the implicit dependency on `params` from `get_from_clause()`. Overall, the intent is understandable, but the formatting and variable scoping prevent higher readability.
Run 3
The code is moderately readable. It uses clear variable names and has some helpful comments explaining the 'why' behind the logic. However, readability suffers from a few issues. The split_having_qualify call has awkward indentation and line breaking, which disrupts the reading flow. The comment block is informative but verbose, making it slightly longer than necessary. Action granularity is mostly one action per line, but the split_having_qualify line packs too much into one line. The try/except/else structure adds moderate nesting, though it is straightforward. Overall, the intent is clear, but formatting and line structure could be improved for better readability.
Run 1
Code Structure: Imports and a single compiler override are logically organized, with a clear fallback followed by SQL construction. Nesting: Shallow conditionals and a try/except/else keep complexity manageable. Clarity of intent: Descriptive names and comments explain the database-specific optimization and its restrictions, though understanding compiler internals requires Django knowledge. Code length: Concise, with comments that justify non-obvious behavior rather than repeat it. Action granularity: Statements generally perform one action per line. Reading flow: Execution proceeds naturally from eligibility checking to query assembly and return, but excessive spacing in the split_having_qualify call disrupts readability. The empty exception handler also requires readers to infer that a full result set needs no WHERE clause.
Run 2
Code Structure: The compiler override is logically organized into eligibility checks, SQL construction, condition compilation, and return. Nesting: An early return keeps nesting shallow; the try/except/else block is straightforward. Clarity of intent: Descriptive names and comments clearly explain the optimized DELETE syntax and its limitations, though Django compiler knowledge is needed. Code length: The implementation is concise, with useful rather than excessive commentary. Action granularity: Statements generally perform one action per line, and SQL assembly is separated into clear steps. Reading flow: Execution proceeds naturally from validation to construction, but the excessive whitespace and misplaced argument on the split_having_qualify call interrupt readability. Overall, the code is highly readable aside from that formatting defect and some unavoidable framework-specific complexity.
Run 3
Code Structure: Imports and a single compiler override are logically organized, with SQL construction proceeding in clear stages. Nesting: An early return keeps control flow flat; the try/except/else adds only modest complexity. Clarity of intent: Descriptive names and comments explain the database-specific optimization and fallback conditions, although understanding Django compiler internals requires domain knowledge. Code length: The implementation is concise, and the explanatory comments are relevant rather than redundant. Action granularity: Statements generally perform one action per line, making query assembly easy to follow. Reading flow: The progression from eligibility checks to FROM and WHERE construction and final output is natural. However, excessive spacing on the split_having_qualify call and insufficient separation before the class definition reduce formatting consistency.