Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

schemadiff: introduce "atomic diffs" concept. #15842

Open
shlomi-noach opened this issue May 6, 2024 · 0 comments
Open

schemadiff: introduce "atomic diffs" concept. #15842

shlomi-noach opened this issue May 6, 2024 · 0 comments
Labels
Component: Query Serving Type: Enhancement Logical improvement (somewhere between a bug and feature)

Comments

@shlomi-noach
Copy link
Contributor

schemadiff already knows how to split incompatible diffs into multiple changes. For example, one cannot add two FULLTEXT indexes in the same ALTER TABLE statement. schemadiff uses the notion of subsequentDiff, a linked list that can be turned into a slice of diffs. With this mechanism, schemadiff can break complex changes into valid, optimized smaller changes.

However, these are not necessarily atomic. One particular use case, changed recently in #15698, is when we drop multiple partitions in one statement, as in ALTER TABLE ... DROP PARTITION p1, p2, p3. This multi-partition statement is in fact the most correct form, because in MySQL you may not run two DROP PARTITION statements in a single ALTER TABLE, and also because it is he most succinct and descriptive form.

So far so good. But for analysis reasons, we sometimes may want to have an even deeper breakdown, so we can identify distinct changes.

Some breakdown can be complex. For example, if we add column and add index on that column, then there is a dependency between the changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Query Serving Type: Enhancement Logical improvement (somewhere between a bug and feature)
Projects
None yet
Development

No branches or pull requests

1 participant