-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[db][protocol] Implement TeamSubscription2 DB shapes and migration #9655
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
9730c9d
to
41cdffb
Compare
FYI, DB looks as expected:
|
/werft run 👍 started the job as gitpod-build-jx-ts2-shapes.2 |
Looking into this now, and reading up the plan. |
Many thanks @AlexTugarev! 😊 Let me know if you have any questions 🙏 |
Friendly ping @AlexTugarev 😇 🧡 |
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.
DBTeamMembership.subscriptionId
and DBSubscription.teamMembershipId
seems to be redundant.
Looking at the usage in 81b41f1#diff-349769928506cc98ef99e13b1d146ae991fd2755d6076cda2ed87b1693eec071R36-R37
What's the benefit?
Thanks for the feedback @AlexTugarev!
This is modelled on For example, when you leave a team, the membership is automatically deleted (leaving no trace), but the subscription is merely cancelled at end of term. This leaves a trace (e.g. for users wondering why they have unlimited hours without a paid subscription, we could see that the still-active subscription came from a team membership that has since been deleted). |
@jankeromnes, I find the cut of the PRs less useful for a review. I understand #8041 is a 🐋, but it seems cutting out the DB shapes doesn't much, as one still need to understand the call sites. How else do you expect this to be reviewed? |
components/gitpod-db/src/typeorm/migration/1650526577994-TeamSubscrition2.ts
Outdated
Show resolved
Hide resolved
Aha, thanks for the feedback @AlexTugarev -- I'm trying to learn how to do smaller PRs, and I thought that this was somewhat self-contained (big low-risk changes that are easy to test, and could in the worst case still be adjusted later when reviewing the call sites). Would you prefer I drop this PR and you review #8041 directly? (It still contains the commit from this PR) |
if (!membership) { | ||
throw new Error("The user is not currently a member of this team"); | ||
} | ||
membership.subscriptionId = subscriptionId; |
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.
from #9655 I can read that the subscription already knows the membership. why storing this link in both directions?
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.
See #9655 (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.
(Let's use this as a thread in here.)
For example, when you leave a team, the membership is automatically deleted (leaving no trace), but the subscription is merely cancelled at end of term. This leaves a trace (e.g. for users wondering why they have unlimited hours without a paid subscription, we could see that the still-active subscription came from a team membership that has since been deleted).
So, what is the DBTeamMembership.subscriptionId
need for then? I couldn't spot any usage.
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.
Sure! So, while this direction of the link is indeed not used in the current code, it was requested in the RFC that this link be materialized in both directions:
- We add a 0..1 reference from
d_b_team_member[ship]
tod_b_subscription
and the opposite reference in analogy to the reference tod_b_team_subscription_slot
.
Source (internal)
And, this made sense to me at the time, because the link between d_b_team_subscription_slot
and d_b_subscription
also went both ways.
As mentioned above, this slight duplication has helped/saved us a few times, for example in customer requests, or to investigate recover from bugs.
Are you proposing to drop the reference from d_b_team_membership
to d_b_subscription
now?
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.
Let's keep this model and quickly move on to Usage-Based / Pay-As-You-Go (which will hopefully deprecate all these subscriptions anyway)
Decision (internal Slack)
Addressed all nits, DB still looks good! (see tables)
|
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.
LGTM!
Many thanks @AlexTugarev !! |
Description
Implement TeamSubscription2 DB shapes and migration.
Part of #7759, split out of #8041
Related Issue(s)
Fixes #9652
How to test
d_b_team_subscription2
+ an additional column in bothd_b_subscription
andd_b_team_membership
tablesRelease Notes
Documentation