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 is moderately readable. It has a clear structure with a single class and method, and the logic is sequential. However, the intent of the override is somewhat obscured by a long explanatory comment and the conditional logic. The nesting is shallow (one if, one try/except), which is good. Action granularity is mostly one action per line, though the list-building and string formatting add slight density. The code is concise overall. The main readability drawbacks are the domain-specific complexity of the SQL compilation logic and the need for background knowledge about Django's compiler internals, which makes the purpose less immediately clear to a general reader.
Run 3
The code is generally readable with clear logical structure and purpose. The comment explains why the custom implementation exists, which aids intent. Nesting is shallow (one if-else block), and action granularity is reasonable, though some lines combine multiple operations. Variable names like `where_sql`, `where_params`, and `from_sql` are descriptive. However, the string formatting using `%` and the manual list assembly slightly reduce clarity. The `try/except FullResultSet` block is a bit abrupt without accompanying explanation, and the conditional logic around when to fall back to `super().as_sql()` could be clearer. Overall, the code is concise and follows a natural reading flow, but minor improvements in formatting and inline comments would enhance readability.
Run 1
Code Structure: A single focused method follows a logical sequence: check compatibility, build SQL, compile filtering, and return SQL with parameters. Nesting: Minimal nesting and an early return keep control flow flat; the try/except/else is straightforward. Clarity of intent: Descriptive names and useful comments explain both the optimization and its limitations, though Django compiler internals require domain knowledge. Code length: Concise for its responsibilities, with comments adding necessary context rather than redundancy. Action granularity: Statements generally perform one action each; SQL formatting expressions remain manageable. Reading flow: Execution proceeds naturally from setup to output. Minor readability drawbacks include imports unused within this snippet, the silent FullResultSet exception handling, and limited visual separation between imports and the class.
Run 2
Code Structure: A single focused method follows a logical sequence: inspect query constraints, select a fallback, construct SQL, and return parameters. Nesting: Shallow conditionals and a try/except/else keep complexity low; the early return avoids additional nesting. Clarity of intent: Descriptive names and useful comments explain both the optimization and its limitations, though Django compiler knowledge is needed to understand the details. Code length: Concise for its functionality, with comments proportionate to the non-obvious behavior. Action granularity: Statements generally perform one action each; tuple unpacking naturally groups related outputs. Reading flow: SQL construction proceeds naturally from DELETE through FROM to WHERE. Minor readability drawbacks include unused imports in this snippet, limited spacing before the class declaration, and the implicit meaning of the empty FullResultSet handler.
Run 3
Code Structure: The method is logically organized into eligibility checking, SQL construction, optional filtering, and return. Nesting: An early return keeps the flow flat, with only a shallow try/except/else block. Clarity of intent: Descriptive names and comments explain both the database optimization and fallback conditions, though Django compiler internals require domain knowledge. Code length: The implementation is concise; comments are substantial but justify non-obvious behavior. Action granularity: Each statement generally performs one action, and tuple unpacking naturally groups related results. Reading flow: Execution proceeds naturally from validation to assembly, although the silent FullResultSet handler and SQL fragment construction require some interpretation.