-
Notifications
You must be signed in to change notification settings - Fork 7
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
feat: database migrations #3457
Conversation
d58d4a6
to
7aa111b
Compare
42eafe8
to
a3485a2
Compare
e88667f
to
d4f0282
Compare
@@ -41,6 +42,12 @@ message MysqlResource { | |||
MysqlResourceOutput output = 1; | |||
} | |||
|
|||
message MigrationResource { |
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.
Please prefix all these types/functions with "SQL", "migrations" is not specific enough.
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.
Just to clarify why I think this is important - it's very likely there will be other kinds of migrations in the future.
go-runtime/goplugin/service.go
Outdated
Schema *schema.Schema | ||
Dependencies []string | ||
BuildEnv []string | ||
AdditionalFiles []string |
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'm 95% sure this should just be part of the ModuleConfig .proto rather than here (cc @matt2e) - this is exactly what it's designed for. Each language plugin then just returns the directory for any migrations, and the build engine does the bundling rather than each runtime having to have custom logic.
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 wasn't sure if we wanted the build engine to modify the schema after the language plugin was finished with it. I can definitely change it but I think it does kinda blur the lines about what is responsible for generating the schema.
I figured language plugins could just re-use the ExtractMigrations function and achieve re-use that way.
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's not a requirement that language plugins be in Go, and in general we try to push as much as possible out of the plugins and into the engine for this reason.
The pattern is that the ModuleConfig tells the BuildEngine where to look for different parts of the build, and the BuildEngine does the work of collecting it into the schema+build. This fits that fairly well. It could be a glob, or a regex, or a map of db names to paths or something.
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 have changed this.
targetDir := t.TempDir() | ||
|
||
// Create dummy migration files | ||
migrationSubDir := filepath.Join(migrationsDir, "testdb") |
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.
Didn't want to use testdata
for the fixtures?
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 thought that was just for integration tests? Also it's possible Chad may have written this test...
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.
Hahaha 😂
Nope testdata
is standard Go for any test that has fixtures.
@@ -729,6 +731,7 @@ module todo { | |||
secret secretValue String | |||
// A database | |||
database postgres testdb | |||
+migration sha256:8cc04c75ab7967eb2ec82e11e886831e00b7cb00507e9a8ecf400bdc599eccfd |
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.
Noice.
switch md := md.(type) { | ||
case *MetadataMigration: | ||
if found { | ||
merr = append(merr, fmt.Errorf("database %q has multiple migration metadata", n.Name)) |
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.
Yeah nice.
e90d83b
to
59d6913
Compare
e03fdd8
to
c0f8696
Compare
I think I have addressed everything, except for the questions around if this should be handled by the build engine or language plugins. |
c0f8696
to
4a50e95
Compare
4a50e95
to
0ea0da2
Compare
return err | ||
} | ||
_, err = db.Get(ctx).Exec("INSERT INTO requests (id,data) VALUES ($1, $2);", req.Id, req.Data) | ||
_, err := db.Get(ctx).Exec("INSERT INTO requests (id,data) VALUES ($1, $2);", req.Id, req.Data) |
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.
So much nicer!
@@ -34,6 +34,9 @@ message ModuleConfig { | |||
// LanguageConfig contains any metadata specific to a specific language. | |||
// These are stored in the ftl.toml file under the same key as the language (eg: "go", "java") | |||
google.protobuf.Struct language_config = 10; | |||
|
|||
// The directory containing the SQL migration files | |||
string sql_migration_dir = 11; |
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's the syntax of the directory? <sql_migration_dir>/<database_name/*.sql
?
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.
No docs yet, but none of the DB stuff has docs yet.
No description provided.