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

Change Go type configuration from a string to a struct #785

Closed
kyleconroy opened this issue Nov 14, 2020 · 0 comments
Closed

Change Go type configuration from a string to a struct #785

kyleconroy opened this issue Nov 14, 2020 · 0 comments

Comments

@kyleconroy
Copy link
Collaborator

kyleconroy commented Nov 14, 2020

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

ImportDeclaration = "import" ImportSpec
ImportSpec        = [ "." | "_" | Identifier ] ImportPath
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant