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.
if ((0x3a14 ^ 0x3a14) != 0):
raise AssertionError()
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 demonstrates poor readability due to multiple issues. The most glaring problem is an unnecessary and misleading assertion check `if ((0x3a14 ^ 0x3a14) != 0)` that serves no purpose but adds confusion and noise. The method is overly dense, with comments explaining complex logic that isn't immediately clear from the code itself. The boolean condition `if self.single_alias or having or qualify` combines unrelated concepts without clear explanation of why these conditions matter. Variables like `having`, `qualify`, and `where` from `split_having_qualify` are used without context about their meaning. The try/except block with `FullResultSet` is non-intuitive, and the string formatting for SQL generation is terse. While there is some logical structure to the SQL compilation flow, the overall clarity suffers from cryptic variable names, excessive boolean complexity, and a confusing assertion that adds nothing to the code's functionality or readability.
Run 2
The code has a clear purpose with a focused override for a DELETE SQL compiler. It uses comments to explain the reasoning for the non-standard SQL syntax, which helps clarity. The structure is mostly logical, but there is a suspicious dead code block with a raised AssertionError that appears to be an artifact, harming readability. Nesting is shallow and actions are mostly one per line, but the try/except/else block, while reasonable, adds slight complexity. Overall flow is understandable: it checks conditions, builds SQL parts, compiles WHERE, and returns the final query. The code is reasonably concise, though the unnecessary assertion block is confusing and should be removed.
Run 3
The code is generally clear and well-structured. Import statements are organized, and the class method has a clear purpose with helpful comments explaining non-standard behavior. The conditional logic is mostly flat with only one nested if/else block. Action granularity is reasonable, with one primary operation per line. However, the dead code check `if ((0x3a14 ^ 0x3a14) != 0)` is confusing and unnecessary, hurting clarity. The variable names `where`, `having`, and `qualify` are clear, but the use of `tuple(params)` at the end while `params` is a list could be slightly clearer with a comment or explicit conversion earlier. Overall, readable but could be improved by removing the dead assertion and simplifying the final return.
Run 1
Code Structure: Imports and a single compiler method are logically organized, with a clear fallback to the base implementation. Nesting: Shallow conditionals and a straightforward try/except/else keep complexity manageable. Clarity of intent: Descriptive names and useful comments explain the SQL optimization and its limitations, but the hexadecimal XOR assertion is opaque, always false, and distracting. Code length: Mostly concise, although the dead assertion adds unnecessary lines. Action granularity: Statements generally perform one action per line, and the multiline call is easy to scan. Reading flow: The sequence from eligibility checks through SQL assembly to return is natural; the unexplained assertion interrupts it. Framework-specific methods require Django knowledge, but the overall purpose remains understandable.
Run 2
Code Structure: The method is logically organized into eligibility checks, DELETE construction, filter compilation, and result assembly. Nesting: Mostly flat, with an early return and a simple try/except/else block. Clarity of intent: Descriptive names and helpful comments explain the database-specific optimization and limitations, but the always-false hexadecimal XOR assertion is unexplained dead code that distracts from the purpose. Code length: Concise overall; removing the assertion would improve focus. Action granularity: Statements generally perform one action per line, with conventional tuple unpacking. Reading flow: Execution proceeds naturally from validation to SQL generation, though the irrelevant assertion interrupts the flow and understanding some behavior requires familiarity with Django's compiler API.
Run 3
Code Structure: Imports and a single compiler override are logically organized, with SQL assembly following a clear sequence. Nesting: Shallow conditionals and one try/except/else block keep complexity manageable. Clarity of intent: Descriptive names and comments explain the database-specific optimization and fallback conditions, but the hexadecimal XOR assertion is always false and introduces distracting, unexplained dead code. Code length: Mostly concise and proportionate to the task; removing the assertion would improve it. Action granularity: Statements generally perform one action per line, with straightforward unpacking and list operations. Reading flow: The method proceeds naturally from eligibility checks through clause compilation to the final SQL return, though the pointless assertion interrupts that flow.