-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[usage] Add db.WorkspaceInstance model in golang #10367
Conversation
cd1cc5b
to
27b8fc0
Compare
cab07ef
to
44c4e93
Compare
/hold |
|
||
type WorkspaceInstance struct { | ||
ID uuid.UUID `gorm:"primary_key;column:id;type:char;size:36;" json:"id"` | ||
WorkspaceID string `gorm:"column:workspaceId;type:char;size:36;" json:"workspaceId"` |
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.
nit: one ID column is UUID, the other string: Why not make both strings? (so far we only have one column type for IDs: string) What's the advantange of UUID?
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.
Workspace Instance ID is an actual UUID, but Workspace ID is something like org-repo-random-string
which isn't a valid UUID
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.
UUID allows you to parse UUIDs and validate before you even hit the DB. UUID is the more appropriate type as it's more specific. For example, it prevents you from inserting something like Workspace{ID: "my-random-string"}
because it won't even compile
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.
parse UUIDs and validate before you even hit the DB
Jup. My point was that it's the only point in the code that imposes that constraint, then. The only constraint we have so far is "equality".
Mentioning this to a) raise awareness and b) to think about how we see this DB layer. So far I thought about it as 100% follower of the primary implementation we have.
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.
And it is. uuid.UUID
serializes as a string. It's the same as using the UUID_COLUMN type in our TypeORM implementation.
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.
Ah! The UUID_COLUMN_TYPE is only there to ensure the width/type of the field is the same everywhere.
The key question is: does uuid.UUID
influence the runtime behavior (e.g., introduces new error modes during parsing? If no I'm happy! 👍
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.
It shouldn't, as long as what is stored in the DB is a valid UUID. I'm gonna run it against the RO replica of staging & prod to batch list all items to validate we don't have underlying violations to verify.
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.
code looks good, tests are green! ✔️
/hold because of this question. I leave it up to you to handle. 🙏
44c4e93
to
c1f1ae7
Compare
ae48e03
to
45f1ca4
Compare
c1f1ae7
to
9f1b591
Compare
/unhold |
/hold |
9f1b591
to
743b6c4
Compare
/unhold |
Description
Same as #10293 but for WorkspaceInstances.
Related Issue(s)
How to test
Unit tests
Release Notes
Documentation
NONE