xxjwxc/gormt: generating Go structs from a MySQL schema

What gormt converts, and who ends up using it

gormt takes a MySQL schema and produces Go source: structs named in big camel case, with gorm tags, JSON tags and the column comments carried over as Go comments. The README states the goal plainly: "You can automatically generate golang sturct from mysql database." The intended reader is a Go developer who already has tables in MySQL and does not want to type forty struct fields by hand, or who inherited a schema and needs a typed starting point for a gorm-based service.

The output is not just the struct. With is_out_func enabled, gormt also emits manager types with methods such as FetchByPrimaryKey, which the README shows wrapping obj.DB.Table(...).Where("id = ?", ID).Find(&result). That makes it a scaffolding tool for the data access layer, not only a type printer. If your project already has a hand-written repository layer, most of that generated code is dead weight you will delete.

How the generation pipeline reads MySQL and writes Go files

The flow is one-directional: connect to MySQL, read table and column metadata, map each column to a Go type, then write files into out_dir. Type mapping is not hardcoded in a single switch; the README points at data/view/cnf/def.go as the place to "enrich data types", which means the mapping table is editable source you can extend for types the default rules miss.

Column comments drive extra behaviour. A comment beginning with [@gorm default:'test'] becomes a gorm tag, and the fuller form [@gorm default:'test';->;<-:create] sets the default and the read/create/write permissions. Foreign keys get their own annotation: [@fk tableName.columnName] in a comment declares that this column references tableName.columnName. The README also lists support for PRIMARY_KEY, UNIQUE, NOT NULL, INDEX and UNIQUE_INDEX, so index and constraint information from the schema is expected to survive into the struct tags.

Two switches change the shape of the output rather than its content. is_null_to_point decides whether a column declared DEFAULT NULL becomes a pointer type. is_table_name decides whether a GetTableName function is emitted. Both are the kind of choice that is cheap to flip at generation time and expensive to change later, once the structs are embedded in your codebase.

Installing gormt and generating your first model package

The README gives two install routes: go get, or a prebuilt archive from the releases page. The go get form is the one to use if you want the current master rather than a tagged archive.

go get -u -v github.com/xxjwxc/gormt@latest

After that, the tool is configured either from a config.yml in the working directory or from flags. The README ships a config.yml at the repository root and describes it as the default configuration source. A minimal version, using the keys exactly as the README lists them, looks like this:

out_dir : "./model"
url_tag : json
db_tag : gorm
simple : false
is_out_sql : false
is_out_func : true
is_foreign_key : true
is_table_name : false
is_null_to_point : false

Running ./gormt with no arguments reads that file. To override the connection details without editing it, the README shows the flag form, where -H is uppercase for host and --port defaults to 3306:

./gormt -H=127.0.0.1 -d=oauth_db -p=qwer -u=root --port=3306 -F=true

There is also a terminal UI, started with ./gormt -g=true, and a plain command mode with -g=false. The help text is available via ./gormt --help, and the README notes that the flag descriptions are in Chinese. Expect the generated files under ./model, one per table, named after the table in camel case.

Where gormt breaks down

The most concrete limitation is stated in the build notes: on Windows, UTF-8 output is not supported, and the README suggests switching the console encoding with CHCP 65001. That is a workaround for a code page problem, not a fix, and it means a Windows user generating structs from a schema with non-ASCII comments should check the written files rather than trust the run.

A second issue is the gap between the repository's dependencies and what the tool claims to support. go.mod pulls in gorm.io/driver/mysql alongside sqlite and sqlserver drivers and a ClickHouse client, but the README describes the tool as a MySQL-to-Go converter and documents MySQL behaviour only. The presence of those drivers does not mean the generation path handles them, and the README does not claim it does.

The third limitation is currency. The last push was on 2021-06-27, and the newest listed release, v2.1.gorm, carries the same timestamp. Nothing in the README describes a compatibility statement against modern gorm versions. If you import gorm v2 today and gormt emits tags aimed at an older tag vocabulary, you will be editing generated files by hand, which removes most of the reason to run the generator.

Finally, gormt is the wrong tool when the schema is not the source of truth. If your Go structs are authoritative and migrations are generated from them, running gormt in the other direction produces a second, competing definition of the same tables.

gormt against SQLBoiler and Pop

The related searches surface SQLBoiler and Gobuffalo Pop, which are the honest comparisons. SQLBoiler also reads an existing database and generates Go, but its output is a full query API with typed column helpers, eager loading and batch insert support, generated from templates you can override. gormt's generated surface is narrower: structs plus manager helpers that call gorm directly, as in the FetchByPrimaryKey example, which issues a Table(...).Where(...).Find(...) chain.

Pop takes the opposite route. It is a full ORM with a CLI that generates models from a database, but the generated code is meant to run inside Pop's own runtime, so you adopt Pop's migrations and connection handling along with the models. gormt assumes you already use gorm and only wants to save you the typing. That is a smaller commitment and a smaller payoff.

The practical difference for a team choosing between them: SQLBoiler gives you a generated data layer you can call without writing SQL by hand, and expects you to keep regenerating it. gormt gives you a starting point you then own, edit and check into your repository.

Licence, maintenance and what upgrading costs

The repository is MIT licensed, with the LICENSE file at the root. MIT permits use, modification and redistribution provided the copyright notice and permission notice are retained, which matters here because generated files are often committed into a private repository. Keeping the notice with the tool, rather than with every generated file, is the usual arrangement, but the licence text itself only states the condition; it is not legal advice and your own review decides how it applies to your distribution.

Maintenance is the real cost. The last push was on 2021-06-27 and the latest listed release is v2.1.gorm from the same date. There is no CHANGELOG in the top-level file listing, and the README does not document an upgrade path or a migration guide between the v1.gorm and v2.1.gorm releases. Upgrading therefore means reading the diff yourself.

The Makefile shows what an upgrade touches. The master target pulls master branches of github.com/xxjwxc/public and three gorm modules:

go get -u github.com/xxjwxc/public@master
go get -u gorm.io/gorm@master
go get -u gorm.io/driver/sqlserver@master
go get -u gorm.io/driver/sqlite@master

Those are floating master references, so rebuilding the tool today can resolve to code the 2021 release never saw. If you build from source, pin the module versions in your own go.mod rather than following that target.

Editorial conclusion

Adopt gormt if you have a stable MySQL schema and want Go structs with gorm tags, JSON tags and comments generated in one pass, and if you are willing to pin a tool whose last push was on 2021-06-27. Do not adopt it if you need SQLite, SQL Server or ClickHouse output, if you expect upstream fixes, or if you want a generator that keeps running in CI. Before committing, verify two things yourself: that the gorm tag output matches the gorm version you actually import, and that the generated manager functions compile against your own model package, since the README points at doc/func.md and genfunc_test.go rather than documenting a supported call contract.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes