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

Properly handle unique=True field collisions on import #193

Closed
Tracked by #153
azaslavsky opened this issue Sep 6, 2023 · 0 comments · Fixed by getsentry/sentry#56023
Closed
Tracked by #153

Properly handle unique=True field collisions on import #193

azaslavsky opened this issue Sep 6, 2023 · 0 comments · Fixed by getsentry/sentry#56023

Comments

@azaslavsky
Copy link

No description provided.

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
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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant