-
-
Notifications
You must be signed in to change notification settings - Fork 1
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
Properly handle unique=True
field collisions on import
#193
Comments
azaslavsky
added a commit
to getsentry/sentry
that referenced
this issue
Sep 8, 2023
UUIDs should always be unique (it's right in the name!). When we import a `UUIDField`, we should generate a new UUID for it, and update all relevant references. Similarly, we enforce `ProjectKey` API token uniqueness. When importing a colliding token, which will likely happen, we generate new API keys for that project. This may break some user flows during cross-region relocation, so there is a note to revisit this decision later. Issue: getsentry/team-ospo#193
azaslavsky
added a commit
to getsentry/sentry
that referenced
this issue
Sep 8, 2023
UUIDs should always be unique (it's right in the name!). When we import a `UUIDField`, we should generate a new UUID for it, and update all relevant references. Similarly, we enforce `ProjectKey` API token uniqueness. When importing a colliding token, which will likely happen, we generate new API keys for that project. This may break some user flows during cross-region relocation, so there is a note to revisit this decision later. Issue: getsentry/team-ospo#193
This was referenced Sep 11, 2023
azaslavsky
added a commit
to getsentry/sentry
that referenced
this issue
Sep 12, 2023
Instead of making a duplicate of the existing token when we copy an org across regions, which could cause problems for downstream code that relies on this uniqueness, we simply make a new instance of the token value. This will break operations that rely on this token as users move from the old org to the new one, but this an okay price to pay to preserve uniqueness. Issue: getsentry/team-ospo#193
azaslavsky
added a commit
to getsentry/sentry
that referenced
this issue
Sep 12, 2023
To avoid creating duplicate `subscription_id`s, rather than naively copying in imported model data, we instead take this data to construct a new call to `create_snuba_subscription`. This will generate an identical subscription (modulo creation/edit dates, which we overwrite), but with a new `subscription_id`. Closes getsentry/team-ospo#193
azaslavsky
added a commit
to getsentry/sentry
that referenced
this issue
Sep 13, 2023
Instead of making a duplicate of the existing token when we copy an org across regions, which could cause problems for downstream code that relies on this uniqueness, we simply make a new instance of the token value. This will break operations that rely on this token as users move from the old org to the new one, but this an okay price to pay to preserve uniqueness. Issue: getsentry/team-ospo#193
azaslavsky
added a commit
to getsentry/sentry
that referenced
this issue
Sep 14, 2023
Instead of making a duplicate of the existing token when we copy an org across regions, which could cause problems for downstream code that relies on this uniqueness, we simply make a new instance of the token value. This will break operations that rely on this token as users move from the old org to the new one, but this an okay price to pay to preserve uniqueness. Issue: getsentry/team-ospo#193
azaslavsky
added a commit
to getsentry/sentry
that referenced
this issue
Sep 14, 2023
To avoid creating duplicate `subscription_id`s, rather than naively copying in imported model data, we instead take this data to construct a new call to `create_snuba_subscription`. This will generate an identical subscription (modulo creation/edit dates, which we overwrite), but with a new `subscription_id`. Closes getsentry/team-ospo#193
azaslavsky
added a commit
to getsentry/sentry
that referenced
this issue
Sep 14, 2023
To avoid creating duplicate `subscription_id`s, rather than naively copying in imported model data, we instead take this data to construct a new call to `create_snuba_subscription`. This will generate an identical subscription (modulo creation/edit dates, which we overwrite), but with a new `subscription_id`. Closes getsentry/team-ospo#193
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: