Skip to content

Add support for custom struct tags #534

Closed

Description

@philippta

When working with structs, struct tags are used to add additional information to a field. This is for example very common when using validation packages. But currently there is no way to add additional struct tags to take advantage of this.

I think it would be a great idea to add a comment syntax just like the -- name:NameForQuery for table columns.

A possible option to express these custom struct tags would be to write create table statements like this:

CREATE TABLE user (
  id   BIGSERIAL PRIMARY KEY,

  -- tags:`validate:"min=10,max=0"`
  username text NOT NULL,

  -- tags:`validate:"gt=18"`
  age  integer NOT NULL,

  -- tags:`validate:"url"`
  website text NOT NULL
);

or alternatively:

CREATE TABLE user (
  id   BIGSERIAL PRIMARY KEY,
  username text NOT NULL,     -- tags:`validate:"min=10,max=0"`
  age integer NOT NULL,       -- tags:`validate:"gt=18"`
  website text NOT NULL       -- tags:`validate:"url"`
);

Activity

  1. huangc28 commented on Aug 14, 2020

    @huangc28

    Has anyone pickup this enhancement yet? It would be useful for generating fake data on model fields. If not I would like to give it a try with proper PSR predicated.

  2. fr3fou commented on Dec 31, 2020

    @fr3fou

    Is there a way to achieve this now?
    I want to ignore the password field on my user struct, like so

    type User struct {
        Password string `json:"-"`
    }
  3. ciazhar commented on Oct 26, 2021

    @ciazhar

    up

  4. tamoore commented on Feb 28, 2022

    @tamoore

    @kyleconroy Would you be open to a solution that utilised the config overrides?

    Something like the following:

    overrides:
      - column: "chat.id"
        custom_struct_tag_key: "gorm"
        go_type: 
          type: "int"
    
    # OR
    
    overrides:
      - column: "chat.id"
        go_type: 
          custom_struct_tag_key: "gorm"
    

    I think this might also need something like custom_tag_value for instances like validate where consumers want to set a custom value. Otherwise, the default would be whatever the json_tags_case_style is set to (otherwise the default format).

    Further to the above, this wouldn't override json tags, it would be in addition to emitting json tags.

    It seems to me that the conversation around including these in the schema is not the right place for this. Struct tags are really just a go concern, so possibly even including it in the definition of the go_type in the override might be a better place.

  5. preslavrachev commented on Mar 20, 2022

    @preslavrachev

    @kyleconroy can we hope to see a feature like this in the foreseeable future? In my project, we started using Gorm way back in time, and it has been something we have been considering moving away from (towards sqlc). However, we rely on some 3rd party code that uses Gorm under the hood, so completely running away from it isn't feasible at the moment.

    If there were a way to let sqlc generate our Gorm-compatible models, this would be fantastic. It's the one thing that's stopping us from getting all in on sqlc.

    The only other alternative is still keep two copies of each model, which isn't that bad, but possibly error-prone.

  6. austincollinpena commented on Mar 21, 2022

    @austincollinpena

    I agree that this seems like a good thing to add to the configuration file.

  7. josharian commented on Apr 25, 2022

    @josharian
    Contributor

    We're facing this right now as well. I'm game to work on it, if we can get to an agreement about the design.

    FWIW, I would prefer adding custom struct tags to the config file, using something like:

    overrides:
      - column: chat.id
        go_struct_tag: 'validate:"required" sometagtype:"some_value"'
  8. austincollinpena commented on Apr 25, 2022

    @austincollinpena

    I like that design

  9. added a commit that references this issue on Apr 25, 2022
    b016f14
  10. josharian commented on Apr 25, 2022

    @josharian
    Contributor

    Implemented in #1569 if anyone wants to kick the tires.

  11. added a commit that references this issue on May 25, 2022
    0cf8ef2
  12. added a commit that references this issue on Jun 10, 2022
    304ba5d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions