feat(migrations): Add in SafeDeleteModel migration operation
#81063
Conversation
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
github-actions
bot
added
the
Scope: Backend
Member
Author
|
Note: Most of the volume of this pr is migrations for tests - Mark them viewed so you can focus on the core part |
wedamija
added a commit
that referenced
this pull request
Nov 21, 2024
This builds on #81063 This adds in `SafeDeleteColumn`, which works the same way as `SafeDeleteModel`, except on database columns. It performs checks that the column doesn't have a db constraint set, and also that it is either nullable or has a db_default set. Similarly to `SafeDeleteModel` we still need to be careful to make sure that the pending deletion merges and deploys first, and then the real deletion.
wedamija
added a commit
to getsentry/sentry-docs
that referenced
this pull request
Nov 21, 2024
This uses the new operations from getsentry/sentry#81063 getsentry/sentry#81098
wedamija
added a commit
that referenced
this pull request
Nov 21, 2024
This builds on #81063 This adds in `SafeDeleteColumn`, which works the same way as `SafeDeleteModel`, except on database columns. It performs checks that the column doesn't have a db constraint set, and also that it is either nullable or has a db_default set. Similarly to `SafeDeleteModel` we still need to be careful to make sure that the pending deletion merges and deploys first, and then the real deletion.
armenzg
reviewed
Nov 21, 2024
markstory
reviewed
Nov 21, 2024
This adds in the `SafeDeleteModel` operation. Most of this pr is testing and monkeypatching Django migrations to be able to hook this in. `SafeDeleteModel` allows us to delete models in two steps without using custom sql. If accepts a deletion_action parameter, which must be passed, and can be either MOVE_TO_PENDING or DELETE. MOVE_TO_PENDING checks that there are no constraints on the table and removes the table from the migation state. We keep track of pending models separately, so that they can be deleted in the next step. DELETE runs the delete command on the database. It is able to still reference the model since we keep track of this in our patched state. If delete is run before MOVE_TO_PENDING then the migration will be rejected. Some care is still needed when using these - we still have to ensure that the PENDING migration runs and fully deploys before the DELETE does. But other than that this reduces the manual error prone sql work around this process a lot.
wedamija
force-pushed
the
danf/migrations-safe-deletes
branch
from
a3cfac3 to
e187edf
Compare
wedamija
added a commit
that referenced
this pull request
Nov 21, 2024
This builds on #81063 This adds in `SafeDeleteColumn`, which works the same way as `SafeDeleteModel`, except on database columns. It performs checks that the column doesn't have a db constraint set, and also that it is either nullable or has a db_default set. Similarly to `SafeDeleteModel` we still need to be careful to make sure that the pending deletion merges and deploys first, and then the real deletion.
Codecov ReportAttention: Patch coverage is ✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## master #81063 +/- ##
=======================================
Coverage 80.33% 80.34%
=======================================
Files 7223 7225 +2
Lines 320085 320155 +70
Branches 20778 20778
=======================================
+ Hits 257156 257218 +62
- Misses 62536 62544 +8
Partials 393 393 |
wedamija
added a commit
that referenced
this pull request
Nov 22, 2024
This builds on #81063 This adds in `SafeDeleteColumn`, which works the same way as `SafeDeleteModel`, except on database columns. It performs checks that the column doesn't have a db constraint set, and also that it is either nullable or has a db_default set. Similarly to `SafeDeleteModel` we still need to be careful to make sure that the pending deletion merges and deploys first, and then the real deletion.
wedamija
added a commit
to getsentry/sentry-docs
that referenced
this pull request
Nov 22, 2024
This uses the new operations from getsentry/sentry#81063 getsentry/sentry#81098
wedamija
added a commit
that referenced
this pull request
Nov 22, 2024
This builds on #81063 This adds in `SafeDeleteColumn`, which works the same way as `SafeDeleteModel`, except on database columns. It performs checks that the column doesn't have a db constraint set, and also that it is either nullable or has a db_default set. Similarly to `SafeDeleteModel` we still need to be careful to make sure that the pending deletion merges and deploys first, and then the real deletion.
wedamija
added a commit
to getsentry/sentry-docs
that referenced
this pull request
Nov 22, 2024
This uses the new operations from getsentry/sentry#81063 getsentry/sentry#81098
harshithadurai
pushed a commit
that referenced
this pull request
Nov 25, 2024
This adds in the `SafeDeleteModel` operation. Most of this pr is testing and monkeypatching Django migrations to be able to hook this in. `SafeDeleteModel` allows us to delete models in two steps without using custom sql. If accepts a deletion_action parameter, which must be passed, and can be either MOVE_TO_PENDING or DELETE. MOVE_TO_PENDING checks that there are no constraints on the table and removes the table from the migation state. We keep track of pending models separately, so that they can be deleted in the next step. DELETE runs the delete command on the database. It is able to still reference the model since we keep track of this in our patched state. If delete is run before MOVE_TO_PENDING then the migration will be rejected. Some care is still needed when using these - we still have to ensure that the PENDING migration runs and fully deploys before the DELETE does. But other than that this reduces the manual error prone sql work around this process a lot. <!-- Describe your PR here. -->
harshithadurai
pushed a commit
that referenced
this pull request
Nov 25, 2024
This builds on #81063 This adds in `SafeDeleteColumn`, which works the same way as `SafeDeleteModel`, except on database columns. It performs checks that the column doesn't have a db constraint set, and also that it is either nullable or has a db_default set. Similarly to `SafeDeleteModel` we still need to be careful to make sure that the pending deletion merges and deploys first, and then the real deletion.
evanh
pushed a commit
that referenced
this pull request
Nov 25, 2024
This adds in the `SafeDeleteModel` operation. Most of this pr is testing and monkeypatching Django migrations to be able to hook this in. `SafeDeleteModel` allows us to delete models in two steps without using custom sql. If accepts a deletion_action parameter, which must be passed, and can be either MOVE_TO_PENDING or DELETE. MOVE_TO_PENDING checks that there are no constraints on the table and removes the table from the migation state. We keep track of pending models separately, so that they can be deleted in the next step. DELETE runs the delete command on the database. It is able to still reference the model since we keep track of this in our patched state. If delete is run before MOVE_TO_PENDING then the migration will be rejected. Some care is still needed when using these - we still have to ensure that the PENDING migration runs and fully deploys before the DELETE does. But other than that this reduces the manual error prone sql work around this process a lot. <!-- Describe your PR here. -->
evanh
pushed a commit
that referenced
this pull request
Nov 25, 2024
This builds on #81063 This adds in `SafeDeleteColumn`, which works the same way as `SafeDeleteModel`, except on database columns. It performs checks that the column doesn't have a db constraint set, and also that it is either nullable or has a db_default set. Similarly to `SafeDeleteModel` we still need to be careful to make sure that the pending deletion merges and deploys first, and then the real deletion.
andrewshie-sentry
pushed a commit
that referenced
this pull request
Dec 2, 2024
This adds in the `SafeDeleteModel` operation. Most of this pr is testing and monkeypatching Django migrations to be able to hook this in. `SafeDeleteModel` allows us to delete models in two steps without using custom sql. If accepts a deletion_action parameter, which must be passed, and can be either MOVE_TO_PENDING or DELETE. MOVE_TO_PENDING checks that there are no constraints on the table and removes the table from the migation state. We keep track of pending models separately, so that they can be deleted in the next step. DELETE runs the delete command on the database. It is able to still reference the model since we keep track of this in our patched state. If delete is run before MOVE_TO_PENDING then the migration will be rejected. Some care is still needed when using these - we still have to ensure that the PENDING migration runs and fully deploys before the DELETE does. But other than that this reduces the manual error prone sql work around this process a lot. <!-- Describe your PR here. -->
andrewshie-sentry
pushed a commit
that referenced
this pull request
Dec 2, 2024
This builds on #81063 This adds in `SafeDeleteColumn`, which works the same way as `SafeDeleteModel`, except on database columns. It performs checks that the column doesn't have a db constraint set, and also that it is either nullable or has a db_default set. Similarly to `SafeDeleteModel` we still need to be careful to make sure that the pending deletion merges and deploys first, and then the real deletion.
Suspect IssuesThis pull request was deployed and Sentry observed the following issues:
Did you find this useful? React with a 👍 or 👎 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
This adds in the
SafeDeleteModeloperation. Most of this pr is testing and monkeypatching Django migrations to be able to hook this in.SafeDeleteModelallows us to delete models in two steps without using custom sql. If accepts a deletion_action parameter, which must be passed, and can be either MOVE_TO_PENDING or DELETE.MOVE_TO_PENDING checks that there are no constraints on the table and removes the table from the migation state. We keep track of pending models separately, so that they can be deleted in the next step.
DELETE runs the delete command on the database. It is able to still reference the model since we keep track of this in our patched state. If delete is run before MOVE_TO_PENDING then the migration will be rejected.
Some care is still needed when using these - we still have to ensure that the PENDING migration runs and fully deploys before the DELETE does. But other than that this reduces the manual error prone sql work around this process a lot.