Description
aka "Stop trying to put everything in a string!"
Currently, we define the go_type
in an override via a string.
overrides:
- go_type: "github.com/gofrs/uuid.UUID"
postgres_type: "uuid"
This string is actually structured data in disguise, as it contains four different pieces of information. Instead of trying to parse this information from a string, break it into a document with fields.
overrides:
- postgres_type: "uuid"
go_type:
import: "github.com/gofrs/uuid"
package: "uuid"
type: "UUID"
pointer: true
This format fixes a few open issues.
Complex import names (#255):
overrides:
- db_type: "uuid"
go_type:
import: "gopkg.in/guregu/null.v3"
package: "null"
type: "Bool"
Types defined in the same package (#177):
overrides:
- db_type: "uuid"
go_type:
type: "CustomUUID"
Built-in types, such as string:
overrides:
- nullable: true
db_type: "text"
go_type:
type: "string"
pointer: true
We'll continue to the support the string for backwards-compatibility reasons, but it will be marked as deprecated in a future release.
I'm curious to get feedback on the names. In the Go AST (see below), each import is defined by an import spec, which consists of a path and an identifier. "import" could be "import_path", but I think the shorter version is still clear. "pointer" could be "is_pointer", but we currently don't use that convention.
One great feature included in #463 is import valdation. By using the tools package, the imports listed in the overrides section can be validated to make sure the package and type both exist. I'd like to add that as a separate configuration option, as it does involve reaching out to the Go module mirror and Go checksum database and requires the Go toolchain to be installed.
Related Issues
- Fully qualified name to Go type not applied, no erros shown in console #462
- Fix complex packages import paths #463
- Improve overriding go_types with more complex import paths #757
ImportDeclaration = "import" ImportSpec
ImportSpec = [ "." | "_" | Identifier ] ImportPath