Documentation
¶
Overview ¶
Package dbmigrate renders registered Go models into a target schema and migrates a database towards it.
SchemaDumper produces the target schema from the models themselves, so it always matches the DDL the runtime applies. Migrate then diffs that schema against the live database through sqldef and applies the difference, or only plans it in dry-run mode. A plan that would drop and re-create an identical definition comes back with advisory text offering the metadata-only rename instead; executing it stays a human decision.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Migrate ¶
func Migrate(schemas []string, dbtyp config.DBType, cfg *DatabaseConfig, opt *MigrateOption) (migrated bool, advisory string, err error)
Migrate applies the schema changes to the database. It returns true if any changes were applied (or would be applied in dry-run mode), and false if the database schema is already up-to-date.
Index renames must run through this migration path BEFORE deploying code that carries the new index name: once the rename is applied, startup table preparation matches the new name and does nothing. With database.auto_migrate enabled (local development, tests), deploying first instead makes gorm's MySQL driver silently DROP and re-CREATE single-column unique indexes during startup, which rebuilds the index with a full table scan and skips every review step. With auto_migrate disabled (the production default) nothing is rebuilt, but the model and the database keep drifting until the migration runs.
When a MySQL or PostgreSQL plan drops and re-creates an identical definition — an index on the same table, or a whole table under a new name — the suspected renames are returned as advisory text with ready-to-run rename statements in that server's syntax. For tables the advisory doubles as a data-loss guard, because the planned DROP TABLE would discard every row that the metadata-only rename keeps. The caller owns when and how to present it; executing the rename stays a human decision.
Types ¶
type DatabaseConfig ¶
type DatabaseConfig struct {
// Database is the schema name on MySQL and PostgreSQL, and the file path
// on SQLite.
Database string
Username string
Password string
Host string
Port int
// SSLMode is the PostgreSQL sslmode parameter; the other dialects ignore it.
SSLMode string
}
DatabaseConfig is the connection the migration runs against.
type MigrateOption ¶
type MigrateOption struct {
// DryRun plans the migration and reports what would change without
// touching the database.
DryRun bool
// EnableDrop lets the plan contain destructive statements. Without it
// sqldef keeps every table, column and index the models no longer declare.
EnableDrop bool
}
MigrateOption tunes a single migration run.
type SchemaDumper ¶
type SchemaDumper struct {
// contains filtered or unexported fields
}
SchemaDumper renders models into the target schema DDL that Migrate diffs against the live database. It runs gorm's migrator in dry-run mode over a mock connection, so the statements are the ones the runtime itself would apply and no database is contacted.
func NewSchemaDumper ¶
func NewSchemaDumper() (*SchemaDumper, error)
NewSchemaDumper opens a dumper on a mock connection of its own. The caller owns it and closes it through Close.
func (*SchemaDumper) Close ¶
func (s *SchemaDumper) Close() (err error)
Close releases the mock connection the dumper renders through. A dumper already closed reports no error.
func (*SchemaDumper) Dump ¶
Dump renders dst as the target schema for driver: one CREATE TABLE per model, each followed by the CREATE INDEX statements of the indexes it declares through its optional Indexes method, and each annotated with the model it came from. Models are sorted by type name, so the same input always renders the same schema.