Conversation
| -- +goose StatementBegin | ||
|
|
||
| CREATE TABLE IF NOT EXISTS premium_tiers ( | ||
| purchase_id VARCHAR(255) NOT NULL, |
|
|
||
| CREATE TABLE IF NOT EXISTS premium_tiers ( | ||
| purchase_id VARCHAR(255) NOT NULL, | ||
| tier_id VARCHAR(255) NOT NULL, |
There was a problem hiding this comment.
Add constraints enforcing the tier names which match the code types
| END$$; | ||
|
|
||
| CREATE TABLE IF NOT EXISTS subscription_tiers ( | ||
| price_id VARCHAR(255) NOT NULL, |
There was a problem hiding this comment.
Call this explicitly stripe_*, because then whoever sees this variable is going to know exactly where it comes from. Otherwise, they have to guess.
There was a problem hiding this comment.
Also, I thought we were going to rename this to stripe_subscription_id. Are we sure price is right?
There was a problem hiding this comment.
Yeah it was my bad, I confused subscription id and price id in the call but checked after to make sure I get this right. Price ID is the correct one (identifying what the user purchased, subscription is is just the id of that specific user subscription).
As for the stripe prefix. In theory we could use this table for a generic implementation. It's just a mapping between any third party identifier of a thing a user can by to our local reference for it. That's why I'd argue against tying it to strongly to stripe
| CREATE TABLE IF NOT EXISTS subscription_tiers ( | ||
| price_id VARCHAR(255) NOT NULL, | ||
| tier_name tier_enum NOT NULL, | ||
| PRIMARY KEY (price_id) |
There was a problem hiding this comment.
The primary key should be tier_name, not price_id, right? Otherwise it could be possible to accidentally add in multiple tiers with the same name but different price_ids, and the code will break.
2 participants
No description provided.