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 not (self.single_alias or having or qualify):
pass
else:
# 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 overall purpose and includes helpful comments explaining the MySQL/MariaDB-specific optimization. However, readability is hampered by inverted conditional logic (`if not condition: pass else: return super().as_sql()`), which obscures intent. The try/except/else structure with `pass` in the except block adds unnecessary complexity. Variable naming is mostly clear, but the mixing of string formatting styles (`%` formatting and `.join()`) and multiple actions within list operations reduce clarity. The method is relatively concise, but the flow is disrupted by the awkward control structures. While the code is not deeply nested, the logical organization could be improved by using a guard clause pattern, which would make the reading flow more natural and the intent more immediately apparent.
Run 2
This code has mixed readability. The structure is somewhat logical, with the ALTERing SQL handled in a focused method, but the nested try/except, an empty except (pass), and inverted logic in the if/else hurt clarity. The intent is explained in comments, but the code itself is ambiguous in places (e.g., the if/else where the 'else' actually handles the main use case). Nesting is moderate, but the flow is inverted, forcing readers to track the 'not' condition before reaching the fallback. Action granularity is mostly one action per line, which is good, but the final string join and tuple creation could be clearer. The variable name 'result' initially holds a list, which is slightly misleading. The code length is reasonable but not concise given the convoluted control flow. Overall, the logic is understandable with effort, but the structure could be flatter and clearer, with more direct condition handling.
Run 3
This code is moderately readable but has confusing control flow. The inverted condition (`if not (...)`: pass; else: return) obscures intent and creates unnecessary nesting. The fallthrough from the try/except/else into the main query-building block is non-intuitive, making the logic harder to follow. Comments explain the reasoning but the structure contradicts them by presenting the simple path as an exception. Variables are clear, and actions are mostly one per line, but the overall flow is disjointed. The method mixes compiler setup, conditional returns, and SQL assembly in a way that requires careful re-reading.
Run 1
Code Structure: Imports and the compiler override are logically organized, with a clear fallback followed by SQL construction. Nesting: Mostly shallow, although the negated condition with an empty pass branch adds unnecessary complexity. Clarity of intent: Descriptive API names and helpful comments explain the database-specific optimization and its limitations; the conditional would be clearer as a direct early return. Code length: Concise overall, with comments providing useful context rather than excessive detail. Action granularity: Statements generally perform one action per line, and tuple unpacking is appropriate. Reading flow: SQL assembly proceeds naturally from DELETE and FROM to WHERE and the final result, but the pass/else structure briefly interrupts that flow.
Run 2
Code Structure: The compiler override is logically organized into eligibility checking, SQL construction, and return. Nesting: Mostly shallow, though the inverted conditional with an empty pass branch adds unnecessary complexity. Clarity of intent: Descriptive names and explanatory comments clearly convey the database-specific optimization and restrictions, but understanding the framework APIs requires Django knowledge. Code length: Concise overall; unused imports and the redundant conditional branch create minor clutter. Action granularity: Statements generally perform one action per line, with conventional tuple unpacking. Reading flow: SQL assembly progresses naturally, and exception handling is localized. Replacing the if-not/pass/else pattern with a direct condition and early return would improve readability.
Run 3
Code Structure: The compiler override is logically organized into compatibility checks, SQL assembly, condition compilation, and return. Nesting: Nesting is shallow, though the negated condition with an empty pass branch introduces unnecessary control-flow friction; a direct guard clause would be clearer. Clarity of intent: Descriptive API names and detailed comments explain the database-specific optimization and fallback constraints, although understanding requires Django SQL compiler knowledge. Code length: The implementation is concise, with comments providing useful context; several imports appear unused in this snippet. Action granularity: Statements generally perform one action per line, and tuple unpacking is appropriate. Reading flow: Execution proceeds naturally from eligibility checks to query construction, but the empty branches and exception-based omission of WHERE require extra attention.