-
Notifications
You must be signed in to change notification settings - Fork 26
feat: Improve migration detection APIs #688
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
Conversation
⏱️ Benchmark results
|
erezrokah
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a few comments, I don't think any are blocking
schema/table.go
Outdated
|
|
||
| // changed pks: drop table // table.IsPrimaryKeyEqual(other) | ||
|
|
||
| func (t *Table) GetChanges(other *Table) []TableColumnChange { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| func (t *Table) GetChanges(other *Table) []TableColumnChange { | |
| func (new *Table) GetChanges(old *Table) []TableColumnChange { |
Maybe this will make it easier to follow? Non blocking
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
new being a reserved word probably can't be used, but the old change is 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
Co-authored-by: Erez Rokah <erezrokah@users.noreply.github.com>
Co-authored-by: Erez Rokah <erezrokah@users.noreply.github.com>
Co-authored-by: Erez Rokah <erezrokah@users.noreply.github.com>
Co-authored-by: Erez Rokah <erezrokah@users.noreply.github.com>
| // type MigrateResult int | ||
|
|
||
| // const ( | ||
| // MigrateResultSuccess MigrateResult = iota | ||
| // MigrateResultDropTable | ||
| // ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this can be removed?
Co-authored-by: Herman Schaaf <hermanschaaf@gmail.com>
Codecov ReportBase: 47.19% // Head: 47.08% // Decreases project coverage by
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more Additional details and impacted files@@ Coverage Diff @@
## main #688 +/- ##
==========================================
- Coverage 47.19% 47.08% -0.12%
==========================================
Files 70 70
Lines 6831 6845 +14
==========================================
- Hits 3224 3223 -1
- Misses 3156 3171 +15
Partials 451 451
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
| type MigrateStrategy struct { | ||
| AddColumn specs.MigrateMode | ||
| AddColumnNotNull specs.MigrateMode | ||
| RemoveColumn specs.MigrateMode | ||
| RemoveColumnNotNull specs.MigrateMode | ||
| ChangeColumn specs.MigrateMode | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be just semantics, but I'm a bit confused by the options here 🤔
The table in the PR description has two options for each entry: Auto Migrate / Drop Table. I think it would be clearer if we used that terminology here, rather than MigrateMode = forced or MigrateMode = safe. forced/safe doesn't convey the same meaning to me drop/auto, but I think that is the intention of this configuration, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I had the same dilemma if to introduce another type, but then it would be quite annoying as we will have OverwriteForceStrategy OverwriteAutoMigrateStrategy and the same for append so I preferred for now just to do one for each mode and then we can understand if it is being dropped or not.
But I think that yes, we potentially will need to change it, I just didn't want to make it even more complex right now as I think we will need to learn a bit more about this API and usage and then do another iteration on the testing API at least.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a comment would help for now. Something like forced == drop table, safe == do not drop table
Co-authored-by: Herman Schaaf <hermanschaaf@gmail.com>
hermanschaaf
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, looks good 👍 If we want to split hairs I'd probably change the naming of the options a bit to make them clearer (IMO), and I spotted a few error messages we may want to fix, but other than that all good :)
Co-authored-by: Herman Schaaf <hermanschaaf@gmail.com>
Co-authored-by: Herman Schaaf <hermanschaaf@gmail.com>
🤖 I have created a release *beep* *boop* --- ## [1.38.0](v1.37.1...v1.38.0) (2023-02-16) ### Features * Improve migration detection APIs ([#688](#688)) ([dc3bedf](dc3bedf)) ### Bug Fixes * Better string methods for TableColumnChange ([#690](#690)) ([a0ec52c](a0ec52c)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
Blocked by cloudquery/plugin-sdk#668 This streamlines migrations, introduce force option and in general should speed up migrations substantially as we only do now one query instead of query per table. Blocked by another take in SDK - cloudquery/plugin-sdk#688
Migration detection APIs take 2.
This will come up also with a Postgres PR and documentation PR:
Basically each destination plugin would have the following table:
Migrations Logic
and we can easily expand it in the code, tests and documentations.
Example of usage in cloudquery/cloudquery#7819