-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Added Usage table #12584
Added Usage table #12584
Conversation
\`workspaceInstanceId\` char(36) NULL, | ||
\`status\` char(10) NOT NULL DEFAULT 'finalized', | ||
\`metadata\` text NOT NULL, | ||
\`_lastModified\` timestamp(6) NOT NULL, |
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.
Do we also want a created
timestamp?
components/gitpod-db/src/typeorm/migration/1662040283793-AddUsageTable.ts
Outdated
Show resolved
Hide resolved
36ce643
to
c2767e6
Compare
c2767e6
to
22fdc4e
Compare
\`_lastModified\` timestamp(6) NOT NULL, | ||
|
||
INDEX \`IDX_usage__attribution_id\` (\`attributionId\`), | ||
INDEX \`IDX_usage_workspaceInstanceId\` (\`workspaceInstanceId\`), |
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.
INDEX \`IDX_usage_workspaceInstanceId\` (\`workspaceInstanceId\`), | |
INDEX \`IDX_usage_workspaceInstanceId\` (\`workspaceInstanceId\`), | |
INDEX \`IDX_db_sync\` (\`_lastModified\`), |
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.
Adding the index for db-sync.
\`description\` varchar(255) NOT NULL, | ||
\`creditCents\` bigint NOT NULL, | ||
\`effectiveTime\` varchar(255) NOT NULL, | ||
\`creationTime\` varchar(255) NOT NULL, |
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.
Should this have an AutoSet on create property?
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.
We don't usually do this for such columns. Also, it might be good to use the same time for all the entries we add in one reconciliation run.
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.
For me this was intended to be a sort of record metadata. Basically storing two timestamps - First creation, and Last Update (and automatically maintaining this by the DB) would give us an audit when something did change or when it first entered the DB.
For our custom application logic, I'd use the effectiveTime
but I'm open on this.
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.
Ok, I was leaning to make it similar to some of the creationTime
fields we already have. But I wasn't too sure about it's usefulness and semantic anyway. I'll change it to _created timestamp(6) ...
.
\`workspaceInstanceId\` char(36) NULL, | ||
\`draft\` BOOLEAN NOT NULL, | ||
\`metadata\` text NULL, | ||
\`_lastModified\` timestamp(6) NOT NULL, |
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.
This should have an auto-update property on it
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 has implicitly. Should I make it explicit?
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.
will make it explicit
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.
I think ensuring that the DB does this for us guards against mistakes we make in code and forget to update the timestamp. It would also reduce the amount of code (the setting of the last modified).
I'd personally like that the DB (explicit) takes care of this rather than doing it our application layer.
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.
Yes, I meant it does it for us, because timestamp(6) NOT NULL does insert/update the current timestamp. But writing it explicitly into the migration file is better.
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.
What I'm after is this:
ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
Is that the behavuour the current statement would 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.
yes. @andrew-farries was sharing this the other day.
But it's better to be explicit.
|
||
require.NoError(t, conn.CreateInBatches(&records, 1000).Error) | ||
|
||
t.Cleanup(func() { |
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.
Thanks for adding this! This ensures that tests clean up after themselves and that multiple tests against hte same table do not interfere
components/usage/pkg/db/usage.go
Outdated
var usageRecords []Usage | ||
result := db. | ||
WithContext(ctx). | ||
Table((&Usage{}).TableName()). |
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.
I think this shouldn't be needed. It "should" be able to reflect that from the Find(&usageRecords)
statement and check if the struct implements the TableName()
interface.
components/gitpod-db/src/typeorm/migration/1662040283793-AddUsageTable.ts
Show resolved
Hide resolved
22fdc4e
to
ad355c4
Compare
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.
This now looks good to me.
/hold in case there's other feedback
Thanks, @easyCZ! Please remove the label yourself anytime, if you want to have this on main in order to rebase on top of it. |
/unhold |
Description
Introduces a usage table to keep track of any account's credit balance.
Related Issue(s)
Fixes #
How to test
Release Notes
Documentation
Werft options: