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 as2(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.
whe, hav, qua = self.query.where.split_having_qualify(
must_group_by=self.query.group_by is not None
)
if self.single_alias or hav or qua:
# 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()
res = ["DELETE %s FROM" % self.quote_name(self.query.get_initial_alias())]
from2, par = self.get_from_clause()
res.extend(from2)
try:
where2, where3 = self.compile(whe)
except FullResultSet:
pass
else:
res.append("WHERE %s" % where2)
par.extend(where3)
return " ".join(res), tuple(par)
Run 1
This code shows poor readability due to excessive abbreviation, unclear variable names, and weak structuring. Names like 'whe', 'hav', 'qua', 'from2', 'par', 'where3' obscure intent and demand significant effort to decipher. The method name 'as2' is cryptic. Although nesting is minimal and the action granularity is decent, the lack of well-named variables and unclear separation of logical steps hurt comprehension. Django-specific patterns (e.g., quote_name, split_having_qualify) are expected, but brevity here sacrifices clarity. The comment explains the reason for the overridden method, but the code itself would benefit from expressive naming and perhaps extraction of helper steps. Overall, the code is functional but not optimized for maintainability or readability.
Run 2
The code has a clear purpose but suffers from readability issues. The structure is logical, and variable names like 'where2', 'where3', and 'par' suggest poor naming. The comment is helpful but overly long relative to the code. Nesting depth is acceptable, with only two levels (if and try/except), but the try/except block with a 'pass' statement before the 'else' clause disrupts natural reading flow. Multiple assignments happen per line (e.g., 'whe, hav, qua = ...'), reducing clarity. The code length is concise, but the string formatting and tuple handling make intent less obvious. Overall, it reads like optimized production code that favors brevity over clarity, making it harder to understand without deep Django internals knowledge.
Run 3
The code has some readability strengths: clear imports, a concise explanatory comment, and mostly flat nesting. However, it suffers from poor variable naming ('whe', 'hav', 'qua', 'res', 'from2', 'par', 'where2', 'where3') which obscures intent. Action granularity is inconsistent—some lines perform multiple operations while others are appropriately separated. The reading flow is disrupted by the split_having_qualify call with a long parameter spanning two lines, and the logic for handling FullResultSet adds a slightly awkward control flow. The method name 'as2' is unclear and appears to be a typo or abbreviation of 'as_sql'. While the code is not excessively long, the terse naming and mixed granularity make it difficult to follow without prior context, hence the low score.
Run 1
Code Structure: The method logically separates fallback handling, DELETE construction, WHERE compilation, and result assembly, though several imports are unused in this snippet. Nesting: Shallow conditionals and a small try/except/else block keep complexity manageable. Clarity of intent: Comments clearly explain the database-specific optimization and limitations, but names such as as2, whe, hav, qua, res, par, where2, and where3 obscure roles; as2 also makes its relationship to the inherited as_sql method unclear. Code length: Compact overall, with detailed comments providing useful context rather than unnecessary verbosity. Action granularity: Most statements perform one action, and tuple unpacking appropriately groups related results. Reading flow: Construction proceeds naturally from FROM to WHERE to the final SQL and parameters, although cryptic identifiers and the silent FullResultSet exception handling require additional interpretation.
Run 2
Code Structure: The method follows a logical sequence: inspect query constraints, fall back when necessary, assemble SQL, and return parameters. Nesting: Shallow branching and a small try/except/else block keep complexity manageable. Clarity of intent: Comments clearly explain the SQL optimization and its limitations, but names such as as2, whe, hav, qua, res, par, and where3 obscure meaning. Code length: The implementation is compact without substantial redundancy, although several imports are unused in the shown snippet. Action granularity: Most lines perform a single operation; tuple unpacking appropriately groups related results. Reading flow: Execution progresses naturally, with an early return simplifying the main path, but abbreviated and numbered names force readers to infer the roles of SQL fragments and parameters.
Run 3
Code Structure: The method is logically organized into condition extraction, fallback selection, SQL assembly, and return, though several imports are unused in the snippet. Nesting: Shallow conditionals and a single try/except/else keep complexity manageable. Clarity of intent: Detailed comments explain the database-specific optimization and its limitations, but names such as as2, whe, hav, qua, res, par, and where3 obscure purpose. Code length: The implementation is compact without substantial repetition; the comments add useful context. Action granularity: Most lines perform one operation, and tuple unpacking appropriately groups related results. Reading flow: Execution proceeds naturally from eligibility checks to query construction, but abbreviated and numbered identifiers force readers to infer what each value represents. More descriptive naming would substantially improve readability.