Skip to content

entc/gen: bake Schema into generated code and allow same table names across schemas#4485

Open
dannyota wants to merge 2 commits into
ent:masterfrom
dannyota:fix/multischema-same-table-names
Open

entc/gen: bake Schema into generated code and allow same table names across schemas#4485
dannyota wants to merge 2 commits into
ent:masterfrom
dannyota:fix/multischema-same-table-names

Conversation

@dannyota

@dannyota dannyota commented Feb 8, 2026

Copy link
Copy Markdown

Fixes #2330

When two PostgreSQL schemas have tables with the same name (e.g., global.templates and lead.templates), code generation fails because Tables() rejects same table names across schemas and the template generates duplicate Go identifiers.

Changes

entc/gen/graph.go

  • Use schema-qualified keys ("schema.table") in the tables map to allow same table names in different schemas
  • Use nodeT map (*Type → *schema.Table) for FK lookups instead of bare table name lookups
  • Add computeTableIdents() to generate unique Go identifiers: pascal(name) by default, pascal(schema) + "_" + pascal(name) on collision
  • Add TableIdent(*schema.Table) string method on Graph, used by the schema template

entc/gen/template/migrate/schema.tmpl

  • Replace all 6 pascal $t.Name / pascal $fk.RefTable.Name usages with $.TableIdent
  • Emit the Schema field in generated table structs when set

dialect/sql/schema/schema.go

  • Fix CopyTables to preserve Schema, Comment, View, Pos fields (previously silently dropped)
  • Use schema-qualified keys in byName map and FK ref lookup

Backward Compatibility

Scenario Behavior
No schema annotation No Schema field emitted, identifiers unchanged. Generated code identical to before.
Single table per name Go identifiers unchanged (e.g., UsersTable).
Same name, different schemas New case — previously errored. Gets schema prefix (e.g., Global_TemplatesTable).
Manual Table.Schema overrides Still work. If Schema is baked in, the manual set is a no-op.
CopyTables Now correctly preserves Schema field (was silently dropped).

Testing

  • Unit tests: TestMultiSchemaSameTableName, TestSingleSchemaTableIdent, TestDuplicateTableNameSameSchema, TestCopyTablesMultiSchema
  • Integration: regenerated multischema/ent/migrate/schema.go with Schema baked in, verified against MySQL 8
  • Regression: all integration tests pass (SQLite, MySQL 5.6/5.7/8, MariaDB, Postgres 10-17)

@dannyota
entc/gen: bake Schema into generated code and allow same table names …
afbef43 
…across schemas

When two PostgreSQL schemas have tables with the same name (e.g.,
global.templates and lead.templates), code generation previously failed
because Tables() rejected same table names across schemas and the
template generated duplicate Go identifiers.

This change:
- Uses schema-qualified keys in the tables map to allow same table
  names in different schemas
- Adds computeTableIdents() to generate unique Go identifiers: uses
  pascal(name) by default, falls back to pascal(schema)+"_"+pascal(name)
  on collision
- Adds TableIdent() method on Graph, used by the schema template
- Emits the Schema field in generated migrate/schema.go table structs
- Fixes CopyTables to preserve Schema, Comment, View, Pos fields and
  use schema-qualified keys for FK ref lookups

Fixes ent#2330
@dannyota dannyota marked this pull request as ready for review February 8, 2026 15:38
@Miraitowa-zcx

Miraitowa-zcx commented May 15, 2026

Copy link
Copy Markdown

The original logic defaults to 'the first schema in the desired reality is the schema to be migrated'. Should we modify ent/dialect/sql/schema
/Lines 696-702 of atlas.go, this is my modification.
desired := schema.New(current.Name) if realm != nil && len(realm.Schemas) > 0 { if s, ok := realm.Schema(current.Name); ok { desired = s } else if a.schema != "" { if s, ok := realm.Schema(a.schema); ok { desired = s } else if len(realm.Schemas) == 1 { desired = realm.Schemas[0] } } else if len(realm.Schemas) == 1 { desired = realm.Schemas[0] } }

@dannyota

dannyota commented May 17, 2026

Copy link
Copy Markdown
Author

Thanks, good catch. I updated the inspect-mode migration logic so it no longer defaults to the first schema in the desired realm when multiple schemas are present.

The selection now prefers:

  1. the desired schema matching the inspected current schema name,
  2. then the configured schema name from WithSchemaName,
  3. then the single desired schema only when there is exactly one.

I also added TestAtlas_DesiredSchema to cover current-schema matching, configured-schema fallback, single-schema compatibility, and the multi-schema no-match case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

PostgreSQL schemas need smarter support

2 participants

@dannyota @Miraitowa-zcx