Configuration

Driver specific configuration option and instructions can be found on their individual pages.

Configuration is done in a bobgen.yaml file in the same directory. A different configuration file can be passed with the -c or --config flag.

The configuration is marshalled in to the Config struct.

// Config for the running of the commands
type Config struct {
    // Additional struct tags to generate (including json, yaml and toml)
    Tags []string `yaml:"tags"`
    // Disable generating factory for models.
    NoFactory bool `yaml:"no_factory"`
    // Disable generated go test files
    NoTests bool `yaml:"no_tests"`
    // Disable back referencing in the loaded relationship structs
    NoBackReferencing bool `yaml:"no_back_referencing"`
    // Delete the output folder (rm -rf) before generation to ensure sanity
    Wipe bool `yaml:"wipe"`
    // Decides the casing for go structure tag names. camel, title or snake (default snake)
    StructTagCasing string `yaml:"struct_tag_casing"`
    // Relationship struct tag name
    RelationTag string `yaml:"relation_tag"`
    // List of column names that should have tags values set to '-' (ignored during parsing)
    TagIgnore []string `yaml:"tag_ignore"`

    Aliases       Aliases       `yaml:"aliases"`
    Replacements  []Replace     `yaml:"replacements"`
    Relationships relationships `yaml:"relationships"`
    Inflections   Inflections   `yaml:"inflections"`

    // Customize the generator name in the top level comment of generated files
    // >>   Code generated by **GENERATOR NAME**. DO NOT EDIT.
    // defaults to "BobGen [plugin] [version]"
    Generator string `yaml:"generator" toml:"generator" json:"generator"`
}

type relationships = map[string][]orm.Relationship

Name	Description	Default
tag_ignore	List of column names that should have tags values set to '-'	[]
relation_tag	Struct tag for the relationship object	"-"
tags	Struct tags to generate	["json", "yaml", "toml"

Type Replacements

There exists the ability to override types that the driver has inferred. The way to accomplish this is through the config file.

replacements:
  - tables: ["table_name"] # What tables to look inside. Matches all tables if empty

    # The match is a drivers.Column struct, and matches on almost all fields.
    # Notable exception for the unique bool. Matches are done
    # with "logical and" meaning it must match all specified matchers.
    # Boolean values are only checked if all the string specifiers match first,
    # and they must always match.
    #
    # Note there is precedence for types.match, more specific things should appear
    # further down in the config as once a matching rule is found it is executed
    # immediately.
    match:
      name: "username" # Matches the column name
      db_type: "varchar(255)" # Matches the database type
      default: "NULL" # Matches the default value
      comment: "The username" # Matches the column comment
      nullable: true # Matches the nullable value. Defaults to false.
      generated: false # Matches the generated value. Defaults to false.
      autoincr: false # Matches the autoincr value. Defaults to false.

    # The replace is what we replace the strings with. You cannot modify any
    # boolean values in here. But we could change the Go type (the most useful thing)
    # or the DBType or FullDBType etc. if for some reason we needed to.
    replace:
      type: "mynull.String"
      imports: ['"github.com/me/mynull"']

Relationships

Relationships are automatically inferred from foreign keys. However, in certain cases, it is either not possible or not desireable to add a foreign key relationship.

We can manually describe relationships in the configuration:

relationships:
  users: # The table name
    - name: "custom_videos_relationship" # A unique identifier used to configure aliases
      sides:
        - from: "users" # Name of the source of the relationship
          to: "videos" # Table name of the other side of the relation
          # mapping of columns from source to destination
          columns:
            - [id, user_id]

          # Is there a unique constraint on the destination columns?
          # this is used to determine if it is a to-one or to-many relationship
          to_unique: false

          # Is the "key" on the destination table?
          # This is used to determine what side to set.
          # For example, if `users.id` -> `videos.user_id,` `to_key` = true
          # so in the generated code, we know to set `videos.user_id` and not `users.id`
          to_key: true

Related Through

The configuration also allows us to describe relationships that span multiple tables. We achieve this by having multiple sides.

In this example configuration, we add a relationship of users to videos through teams. The generated user model with have a Videos relation.

relationships:
  users:
    - name: "users_to_videos_through_teams"
      sides:
        - from: "users"
          to: "teams"
          columns: [[team_id, id]]
          to_unique: true
          to_key: false
        - from: "teams"
          to: "videos"
          columns: [[id, team_id]]
          to_unique: false
          to_key: true

Related Where

The configuration also allows us to describe relationships that are not only based on matching columns but also columns with static values. For example, we may want to add a relationship to teams for verified members.

relationships:
  users:
    - name: "users_to_videos_through_teams"
      sides:
        - from: "teams"
          to: "users"
          columns: [[id, team_id]]
          to_unique: false
          to_key: true
          to_where:
            - column: "verified"
              value: "true"

Aliases

Names are automatically generated for you. If you name your database entities properly you will likely have descriptive names generated in the end. However in the case where the names in your database are bad AND unchangeable, or bob's inference doesn't understand the names you do have (even though they are good and correct) you can use aliases to change the name of your tables, columns and relationships in the generated Go code.

Note: It is not required to provide all parts of all names. Anything left out will be inferred as it was in the past.

# Although team_names works fine without configuration, we use it here for illustrative purposes
aliases:
  tables:
    team_names:
      up_plural: "TeamNames"
      up_singular: "TeamName"
      down_plural: "teamNames"
      down_singular: "teamName"
      columns: # Columns can be aliased by name
        uuid: "ID"
      relationships: # Relationships can be aliased by name
        team_id_fkey: "Owner"

Inflections

With inflections, you can control the rules used to generate singular/plural variants. This is useful if a certain word or suffix is used multiple times and you do not wnat to create aliases for every instance.

inflections:
  plural: # Rules to convert a suffix to its plural form
    ium: ia
  plural_exact: # Rules to convert an exact word to its plural form
    stadium: stadia
  singular: # Rules to convert a suffix to its singular form
    ia: "ium"
  singular_exact: # Rules to convert an exact word to its singular form
    stadia: "stadium"
  irregular: # Singular -> plural mappings of exact words that don't follow conventional rules
    radius: "radii"