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 well-structured with a clear, documented purpose. It uses a single class with one method, moderate nesting (only one level), and natural reading flow. The inline comments explain the MySQL/MariaDB-specific optimization, making intent clear. Action granularity is mostly good, with one primary operation per line, though some lines combine logic (e.g., the where/having/qualify split assignment). Variable names are descriptive. The only minor readability issues are the slightly dense comment block and the try/except/else block, which adds a small amount of cognitive load. Overall, it is concise, modular, and easy to follow.
Run 2
The code is logically structured and follows a clear purpose, but readability is hindered by dense logic and a lengthy comment. The method has moderate nesting (if/else within try/except) and splits a key operation across multiple lines, which impacts clarity. The initial comment is helpful but verbose. The condition for falling back to super().as_sql() is not immediately obvious due to combined checks. Variable names are clear, and actions are mostly one per line, but the overall flow requires careful parsing to understand why the custom SQL is built. The code is concise but could benefit from breaking the logic into smaller helper methods or clearer conditionals to improve reading flow.
Run 3
The code is reasonably structured and mostly readable, but it has some clarity and flow issues. The initial comment is helpful for understanding why custom SQL is generated. However, the logic branches early with a condition that has a comment, which slightly disrupts reading flow. The variable names are clear, and each action is generally on its own line, but the try/except block with `pass` and the subsequent `else` adds mild cognitive overhead. The `result` list construction is straightforward, but the mixed use of string formatting and list extension makes the final SQL assembly slightly harder to follow. Nesting is shallow, which is good. Overall, the code is understandable but could be more polished for readability, especially in the exception handling and SQL assembly sections.
Run 1
Code Structure: Imports and a single focused compiler override provide clear organization. Nesting: An early return keeps control flow mostly flat; the try/except/else adds only modest complexity. Clarity of intent: Descriptive identifiers and useful comments explain the SQL optimization and fallback conditions, though Django compiler knowledge is needed to understand the details. Code length: The implementation is concise, with comments proportionate to the non-obvious behavior. Action granularity: Each statement performs one clear operation; tuple unpacking naturally groups related results. Reading flow: The method progresses logically from checking applicability to assembling SQL, compiling filters, and returning SQL with parameters. Minor readability limitations include dense framework-specific expressions, an implicit no-filter path through the empty exception handler, and unused imported compiler classes in this excerpt.
Run 2
Code Structure: The compiler subclass contains a focused method organized into eligibility checks, SQL construction, condition compilation, and return. Nesting: An early return keeps the main path flat; the try/except/else adds only modest complexity. Clarity of intent: Descriptive names and useful comments explain both the optimization and its limitations, though Django compiler internals require domain knowledge. Code length: The implementation is concise, with comments providing relevant context rather than unnecessary detail. Action granularity: Statements generally perform one action per line, and multiline expressions improve readability. Reading flow: Execution progresses naturally from checking applicability to assembling the query and parameters. Minor drawbacks include several imports unused in the shown snippet, limited spacing before the class definition, and an exception handler whose silent pass requires understanding FullResultSet.
Run 3
Code Structure: The compiler subclass and single overridden method are logically organized, with a clear fallback followed by SQL construction. Nesting: Shallow conditionals and a try/except/else keep complexity low; the early return avoids additional nesting. Clarity of intent: Descriptive names and comments explain both the optimization and its SQL limitations, although Django compiler knowledge is needed to fully understand the implementation. Code length: Concise for the functionality, with useful rather than redundant comments; several imports are unused in this snippet. Action granularity: Statements generally perform one operation per line, and multiline calls improve readability. Reading flow: The method naturally progresses from checking compatibility to assembling clauses and returning SQL with parameters. The silent FullResultSet handling and framework-specific terminology slightly reduce accessibility.