diagram2codeConvert PlantUML to GORM (Go)
Generate production-ready GORM (Go) ORM code from your PlantUML diagrams in seconds.
🚀 View the Roadmap to see which frameworks are coming next.
How the PlantUML to GORM (Go) conversion works
PlantUML entity diagrams are the standard in many enterprise and Java-adjacent teams, with first-class tooling in IDEs and Confluence. Entities declare mandatory fields with a leading *, and stereotypes like <<FK>> mark key columns.
Entities are `entity Name { … }` blocks — a leading `*` marks mandatory (NOT NULL) fields, `<<FK>>` marks foreign keys, and relationships use the same cardinality arrows as Mermaid (`User ||--o{ Post`). Quoted display names (`entity "User Account" as ua`) become table comments.
Paste your PlantUML source into the editor above and the engine parses it into an
intermediate schema — tables, columns, relationships, indexes — then generates
GORM (Go) code from that model. Anything the diagram
syntax can't express (NOT NULL, defaults, enums, CHECK constraints, composite indexes)
you add with comment directives like ' ::NN, ::DEFAULT(now()) on the line
above a column. The PlantUML reference documents the
full vocabulary.
What the generator emits for GORM (Go)
- one Go struct per table with exported PascalCase fields
- gorm struct tags: column names, primaryKey, uniqueness, not-null
- association fields for one-to-many, many-to-one, one-to-one, and many-to-many relationships
- ON DELETE constraint tags only when the diagram declares them — no surprise cascades
- json tags alongside the gorm tags, ready for API serialization
Type mapping: PlantUML to GORM (Go)
Diagram column types are logical — the generator maps each one to the idiomatic GORM (Go) type. These are the exact mappings the engine uses:
| Diagram type | GORM (Go) type | Notes |
|---|---|---|
int | uint | GORM's conventional PK type |
string | string | |
text | string | |
decimal | float64 | |
boolean | bool | |
date | time.Time | |
timestamp | time.Time | imports time automatically |
uuid | string | |
bigint | uint64 | |
blob | []byte |
Keys, relationships, and enums
`int id PK` becomes `ID uint` tagged `gorm:"primaryKey"` — the GORM convention that AutoMigrate recognizes as an auto-increment key. Nullable columns become pointer types (*string, *time.Time).
Each relationship generates both sides: the FK scalar field on the child, a parent navigation field (`User User`), and a slice on the parent (`Posts []Post`). Cascade tags are only added when the diagram explicitly sets onDelete.
`::ENUM(active, inactive)` generates a named Go string type with typed constants for each value, and the struct field uses that type — so invalid states fail at compile time, not at runtime.
Frequently asked questions
Do the generated structs work with GORM AutoMigrate?
Yes — fields carry primaryKey, not-null, unique, and column tags that AutoMigrate reads directly. The same diagram can also generate plain SQL DDL if you prefer explicit migrations.
How are nullable columns represented in Go?
As pointer types: a nullable string becomes *string, a nullable timestamp *time.Time. Non-nullable columns use value types.
What does an enum column become in Go?
A named string type plus typed constants (e.g. type Status string, StatusActive Status = "active"), giving you compile-time safety GORM tags alone cannot provide.
Will relationships cascade deletes by default?
No. Constraint tags like OnDelete:CASCADE are emitted only when your diagram declares them via ::RELATIONSHIP[onDelete: CASCADE] — mirroring how the SQL generators behave.