[usage] Define db.Workspace model

[easyCZ]

Description

Define Workspace model in Golang.

Firstly, the model is generated from the table schema using

go install github.com/smallnest/gen@latest
gen \
	--sqltype=mysql \
	--connstr "<CONN_STRING>" \
	--database gitpod \
	--gorm \
	--table <table_name> \
	--overwrite \
	--json

It is then adjusted to correctly parse timestamps. In particular, we use VarChar for date times in our Typescript ORM model. This requires a custom serialization type (in this PR, it's VarcharTime) to correctly serialize.

This PR also adds a compatibility test with existing data by inserting the data Raw into the DB, and then querying it back to ensure the data matches.

Related Issue(s)

• Part of Define db models in Golang #10317

How to test

Unit tests

Release Notes

NONE

Documentation

NONE

[svenefftinge]

This is a different format to what we currently store in the DB (2006-01-02T15:04:05.999999999Z07:00 vs. 2006-01-02T15:04:05.999Z) and wouldn't parse using JS new Date(<string>).

[easyCZ]

String() is only used for printing it out in a human readable form. It's the interface to Stringer() which printers use to serialize a struct. Given that the format used by JS is fairly non-standard, the human readable format here is the standard RFC3339.

There may be gotchas in other places with timestamps, and I'll be adding much more in regards to tests for those. For now, we're focused on reading records only so writes (while important) are not as a big of a deal at this point.

[easyCZ]

A secondary problem with what we store right now is that we abuse VarChar to store timestamps. We rely on somewhat obscure feature of MySQL which allows for VarChart timestamp comparisons to work. The same, for example, is not true in PostgreSQL

[geropl]

String() is only used for printing it out in a human readable form

@easyCZ Despite what format is standardized where, we should really thrive to have one format everywhere. Everything else will give us headaches when doing cross-service deugging.

[geropl]

A secondary problem with what we store right now is that we abuse VarChar to store timestamps

While I admin that this solution disturbed my personally feeling of "this is not the way it should be done (sic)" I think it worked rather well.

We rely on somewhat obscure feature of MySQL which allows for VarChart timestamp comparisons to work

I think it's regular string ordering, and not that far fetched. 😉

The same, for example, is not true in PostgreSQL

True, but we would not translate the current scheme 1:1 to postgresql, anyway. Even if we were to do it today. 🙃

[geropl]

That being said, I'm fine with having this method returning the RFC3339 format. But let's please be careful to not confuse things in code, so we end up with reporting to different formats somewhere (so far there only ever has been one). 🙏

[easyCZ]

Usage of ISO 8601 is pretty non standard in Go. I'd strongly recommend that for human consumption, we stick with the standard way.

IMO, this is a non-issue in the bigger picture of this PR. But if it enables approval of this PR and allows us to progress usage based billing, I'll happily change it.

[easyCZ]

As promised, a follow-up to this issue is in a PR now: #10490 (with tests)

[geropl]

❓ Why the uncommon JSON naming scheme? 🤔

[easyCZ]

I didn't notice the JSON declaration here. It's what came from the code-generator. I'll update them to match column names.

[easyCZ]

In go, underscore case is the default for json fields so that's likely why the generator default to these.

[easyCZ]

Fixed.

[geropl]

Looks good, and thx for the tests!

/hold because of this comment: https://github.com/gitpod-io/gitpod/pull/10293/files#r885609211

I bet you have a good reason, and leave it to your judgement to adjust if possible (to avoid potential future confusion). 👍

[easyCZ]

/hold because of this comment: #10293 (files)

I bet you have a good reason, and leave it to your judgement to adjust if possible (to avoid potential future confusion). 👍

I'll add a follow-up to add additional tests for both reading and writing to ensure compatibility with existing data layer. I'll cross-reference this comment to an example printout and we can discuss further there.

I'll be landing this to unblock additional data models and progress usage based billing. Thank you for the comments and reviews!

[geropl]

I'll be landing this to unblock additional data models and progress usage based billing. Thank you for the comments and reviews!

Thank you @easyCZ ! 🙏

[easyCZ]

/unhold