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

Added Usage table #12584

Merged
merged 1 commit into from
Sep 2, 2022
Merged

Added Usage table #12584

merged 1 commit into from
Sep 2, 2022

Conversation

svenefftinge
Copy link
Member

@svenefftinge svenefftinge commented Sep 1, 2022

Description

Introduces a usage table to keep track of any account's credit balance.

Related Issue(s)

Fixes #

How to test

Release Notes

NONE

Documentation

Werft options:

  • /werft with-preview

\`workspaceInstanceId\` char(36) NULL,
\`status\` char(10) NOT NULL DEFAULT 'finalized',
\`metadata\` text NOT NULL,
\`_lastModified\` timestamp(6) NOT NULL,
Copy link
Member

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?

@roboquat roboquat added size/L and removed size/M labels Sep 1, 2022
@svenefftinge svenefftinge marked this pull request as ready for review September 2, 2022 07:04
@svenefftinge svenefftinge requested a review from a team September 2, 2022 07:04
@github-actions github-actions bot added the team: webapp Issue belongs to the WebApp team label Sep 2, 2022
\`_lastModified\` timestamp(6) NOT NULL,

INDEX \`IDX_usage__attribution_id\` (\`attributionId\`),
INDEX \`IDX_usage_workspaceInstanceId\` (\`workspaceInstanceId\`),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
INDEX \`IDX_usage_workspaceInstanceId\` (\`workspaceInstanceId\`),
INDEX \`IDX_usage_workspaceInstanceId\` (\`workspaceInstanceId\`),
INDEX \`IDX_db_sync\` (\`_lastModified\`),

Copy link
Member

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,
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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,
Copy link
Member

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

Copy link
Member Author

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will make it explicit

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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() {
Copy link
Member

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

var usageRecords []Usage
result := db.
WithContext(ctx).
Table((&Usage{}).TableName()).
Copy link
Member

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.

@svenefftinge svenefftinge reopened this Sep 2, 2022
@roboquat roboquat added size/L and removed size/XS labels Sep 2, 2022
Copy link
Member

@easyCZ easyCZ left a 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

@svenefftinge
Copy link
Member Author

Thanks, @easyCZ! Please remove the label yourself anytime, if you want to have this on main in order to rebase on top of it.

@easyCZ
Copy link
Member

easyCZ commented Sep 2, 2022

/unhold

@roboquat roboquat merged commit f54482b into main Sep 2, 2022
@roboquat roboquat deleted the se/usage-table branch September 2, 2022 09:33
@roboquat roboquat added deployed: webapp Meta team change is running in production deployed Change is completely running in production labels Sep 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed: webapp Meta team change is running in production deployed Change is completely running in production release-note-none size/L team: webapp Issue belongs to the WebApp team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants