docs(cascade): materialization is required by reverse-topo delete order, not just MySQL 1093#208
Open
dimitri-yatsenko wants to merge 1 commit into
Open
docs(cascade): materialization is required by reverse-topo delete order, not just MySQL 1093#208dimitri-yatsenko wants to merge 1 commit into
dimitri-yatsenko wants to merge 1 commit into
Conversation
…er, not just MySQL 1093
The cascade spec framed master materialization purely as a MySQL error 1093 workaround ('which both backends accept'). The backend-independent reason: Table.delete deletes in reverse-topological order, so the Part is deleted before the Master; a live master restriction referencing the Part would strand the Master on any backend, PostgreSQL included. Reframe the Materialization section and Limitations note accordingly (MySQL 1093 is a secondary consequence).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The cascade spec's "Materialization at the Master" section justified materialization purely as a MySQL error 1093 workaround ("which both backends accept"), mirroring a gap also found in the code docstring during the 2.3.1
dj.Diagramreview.The backend-independent reason:
Table.deletedeletes per-table in reverse-topological order (leaves first), so the originating Part is deleted before its Master. A live master restriction referencing that Part would match zero rows by the time the Master's own DELETE runs — silently stranding the Master on any backend, PostgreSQL included. MySQL 1093 (the self-referential subquery) is a secondary consequence.This reframes the Materialization section and the Limitations note so the spec cannot be read as licensing a "PostgreSQL has no 1093, so skip it" optimization. Docs-only.