Refactor go codegen to plugin types #1460
Conversation
| @@ -28,6 +28,8 @@ message Override { | |||
| string column_name = 8 [json_name="column_name"]; | |||
|
|
|||
| PythonType python_type = 9; | |||
|
|
|||
| ParsedGoType go_type = 10; | |||
There was a problem hiding this comment.
lol. I need to set up some tooling to auto format the proto files. For now, proto files should use spaces instead of tabs. It's not a big deal though.
| Comment: typ.Comment, | ||
| Vals: typ.Vals, | ||
| }) | ||
| case *catalog.CompositeType: |
There was a problem hiding this comment.
i assume the proto has Enums instead of Types because it it hard to represent a Enum | CompositeType in proto. this could also be a oneof maybe
There was a problem hiding this comment.
Yes, you're correct that oneof is the correct way to handle this type of polymorphism. You can see this in the Python AST proto file. For now I'm happy to keep these as two separate arrays.
There was a problem hiding this comment.
ah thanks, i missed the existing usage of oneof. i am happy to keep this as is or take a suggested refactor
There was a problem hiding this comment.
Fine to keep this for now
| } | ||
|
|
||
| for _, ct := range schema.CompositeTypes { | ||
| // XXX: old code had a bug? |
There was a problem hiding this comment.
i think the old code... did not check that the name/schema actually matched? but this is conjecture and i did not try to write a test
There was a problem hiding this comment.
Yeah, I think the current composite type support is broken at best, so this feels like a step in the right direction.
|
This is awesome! Hoping to review this later tonight |
| Comment: typ.Comment, | ||
| Vals: typ.Vals, | ||
| }) | ||
| case *catalog.CompositeType: |
There was a problem hiding this comment.
Yes, you're correct that oneof is the correct way to handle this type of polymorphism. You can see this in the Python AST proto file. For now I'm happy to keep these as two separate arrays.
internal/codegen/golang/compat.go
Outdated
| ) | ||
|
|
||
| func sameTableName(n *ast.TableName, f core.FQN, defaultSchema string) bool { | ||
| func sameTableName(n *plugin.Identifier, f core.FQN, defaultSchema string) bool { |
There was a problem hiding this comment.
We should refactor this to match the signature from the codegen/python so that it doesn't depend on the core package.
internal/codegen/golang/result.go
Outdated
| SQLPackage: sqlpkg, | ||
| } | ||
| } else if len(query.Params) > 1 { | ||
| var cols []goColumn | ||
| for _, p := range query.Params { | ||
| cols = append(cols, goColumn{ | ||
| id: p.Number, | ||
| id: int(p.Number), // XXX: ?? |
There was a problem hiding this comment.
Go can be weird. Casting a int32 to an int is fine.
| } | ||
|
|
||
| for _, ct := range schema.CompositeTypes { | ||
| // XXX: old code had a bug? |
There was a problem hiding this comment.
Yeah, I think the current composite type support is broken at best, so this feels like a step in the right direction.
| @@ -28,6 +28,8 @@ message Override { | |||
| string column_name = 8 [json_name="column_name"]; | |||
|
|
|||
| PythonType python_type = 9; | |||
|
|
|||
| ParsedGoType go_type = 10; | |||
There was a problem hiding this comment.
lol. I need to set up some tooling to auto format the proto files. For now, proto files should use spaces instead of tabs. It's not a big deal though.
protos/plugin/codegen.proto
Outdated
| @@ -131,6 +171,7 @@ message Query | |||
| repeated Parameter params = 5 [json_name="parameters"]; | |||
| repeated string comments = 6 [json_name="comments"]; | |||
| string filename = 7 [json_name="filename"]; | |||
| Identifier InsertIntoTable = 8; | |||
There was a problem hiding this comment.
This should be insert_into_table.
|
thanks for looking! i addressed/responded to comments here. |
| func goInnerType(r *compiler.Result, col *compiler.Column, settings config.CombinedSettings) string { | ||
| columnType := col.DataType | ||
| func goInnerType(req *plugin.CodeGenRequest, col *plugin.Column) string { | ||
| columnType := dataType(col.Type) |
There was a problem hiding this comment.
oh, one more thought: it might be worth removing DataType from the proto. I fell into the pit where it's not actually filled but available on the struct.
I suspect that https://github.com/stephen/sqlc/blame/32f4c968857273582f71d01b72fdf85589548f1d/internal/codegen/python/gen.go#L199 might be wrong? probably wants to also dataType(col.Type)
There was a problem hiding this comment.
Having both is confusing and error-prone. Let's remove it in another PR
See sqlc-dev#1460 (comment) DataType is never filled in so this comparison is buggy. This change mirrors what the go gen.go does instead.
See sqlc-dev#1460 (comment) DataType is never filled in so this comparison is buggy. This change mirrors what the go gen.go does instead. Deleting a field from proto can be not safe for compat, so we could use https://developers.google.com/protocol-buffers/docs/proto3#reserved, but I think these protos are transient so it should be ok.
See #288, #923, #1416 .
(hi @kyleconroy!)
I got excited about the plugin api and wanted to try a few things out with the golang code generation...
There are a couple questionable things in here that I wasn't sure about - will add some comments about them. If you think this work is worth continuing with, I'd be happy to try to clean it up and put it in an upstreamable state.
The tests currently pass.