[Tracking issue]: AutoMigrator Improvements

[bevzzz]

• Replace ordered.Map with slices in public APIs (refactor(automigrate): Limit ordered.Map usage to migrator internals #1164)
• Make migrate.comment and exported type (chore: rename migrate.comment to migrate.Unimplemented #1165)
• Exclude foreign keys from database inspection (fix(gh-1160): add WithExcludeForeignKeys option #1162)
• Exclude tables /foreign keys that match a pattern (comment) (upd: foreign keys are not excluded by name)
• Avoid redundant migrations for autoincrement column (AutoMigrate doesn't fully handle autoincrement for postgres #1159)
• Add option to generate migration file names (comment)
• ❔ Pass migrator options via WithMigratorOption instead of duplicating With<Option>Auto()

[bevzzz]

And I needed to be able to set the directory and the output filenames.

@bgrant0607 wrt the output filenames: currently the autogenerated one'd look like so 20250508184622_public_auto.sql. If there was an option to control filenames would you expect it to:

• let you create the whole filename?
• let you create just the "description" part and always append the timestamp?
• some combination of both? e.g. WithFileNameFunc(fn func() string, timestamp boolean))

Are there any parameters that would be useful to pass to that fn?

I'd appreciate your input on that.

cc @j2gg0s @Aoang

[j2gg0s]

And I needed to be able to set the directory and the output filenames.

@bgrant0607 wrt the output filenames: currently the autogenerated one'd look like so 20250508184622_public_auto.sql. If there was an option to control filenames would you expect it to:

• let you create the whole filename?
• let you create just the "description" part and always append the timestamp?
• some combination of both? e.g. WithFileNameFunc(fn func() string, timestamp boolean))

Are there any parameters that would be useful to pass to that fn?

I'd appreciate your input on that.

cc @j2gg0s @Aoang

• Add an options parameter that allows users to pass in a function which takes input and returns the filename.
  • The current input is schema; whether other parameters should be included needs to be carefully considered and decided, in order to avoid future compatibility issues.
• Define the current behavior and other reasonable defaults as functions, and use one of them as the default option.
• As long as there’s no risk involved, I lean toward offering maximum flexibility.

[snoweuph]

Primary Keys don't really work in the Generator, it seems to only take the one from the last Model specified

type MemberProfile struct {
	bun.BaseModel `bun:"table:member_profile"`
	Id            string                   `bun:"id,pk"`
	Username      string                   `bun:"username"`
	Displayname   string                   `bun:"displayname"`
	Email         string                   `bun:"email"`
	Avatar        string                   `bun:"avatar"`
	GpgPublicKey  string                   `bun:"gpg"`
	Localized     []MemberProfileLocalized `bun:"rel:has-many,join:id=id"`
	Links         []MemberProfileLink      `bun:"rel:has-many,join:id=id"`
}

type MemberProfileLocalized struct {
	bun.BaseModel   `bun:"table:member_profile_localized"`
	MemberProfileId string `bun:"id,pk"`
	Lang            lang   `bun:"lang,pk"`
	About           string `bun:"about"`
}

type MemberProfileLink struct {
	bun.BaseModel   `bun:"table:member_profile_link"`
	MemberProfileId string `bun:"id,pk"`
	Type            string `bun:"type,pk"`
	Url             string `bun:"url"`
}

results in:

SET statement_timeout = 0;CREATE TABLE "member_profile_link" ("id" VARCHAR NOT NULL, "type" VARCHAR NOT NULL, "url" VARCHAR, PRIMARY KEY ("id", "type"));
CREATE TABLE "member_profile_localized" ("id" VARCHAR NOT NULL, "lang" VARCHAR NOT NULL, "about" VARCHAR);
CREATE TABLE "member_profile" ("id" VARCHAR NOT NULL, "username" VARCHAR, "displayname" VARCHAR, "email" VARCHAR, "avatar" VARCHAR, "gpg" VARCHAR);

As we can see the member_profile_localized and member_profile are missing their primary keys

[bevzzz]

@snoweuph thank you for reporting this -- that's an actual bug you found there. I will add a fix.

[giautm]

Hey, I'm from Atlas team (ariga/atlas). I saw you guys trying implement the Auto Migration engine with custom logic there. You may want to use Atlas as the migration engine - like what ent/ent using in its auto migration. So you guys don't need to dealing with SQL statement, and handle compatible for versions of database. Let Atlas takes care about the migrations.

• https://github.com/ent/ent/blob/master/dialect/sql/schema/atlas.go

What you guys need is define the mapping between the Go structure using Bun logic, and the DSL that understanding by Atlas:

• https://github.com/ariga/atlas/blob/master/sql/schema/schema.go

Then, call Atlas to generate migration plan.

[bevzzz]

hey @giautm! interesting suggestion -- I'm going to look into this on the weekend 👌

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. If there is no update within the next 7 days, this issue will be closed.