sea-orm: sea-orm-cli migrate doesn't respect DATABASE_SCHEMA in .env file
Description
Running the command:
sea-orm-cli migrate ...
Always runs migrations against the public schema in PostgreSQL rather than the schema specified in .env
Steps to Reproduce
- Create
.envfile withDATABASE_SCHEMA=not_public - Run
sea-orm-cli migrate...
Expected Behavior
Migrations are run in specified schema
Actual Behavior
See that all migrations were run in public schema
Versions
└── sea-orm v0.6.0
├── sea-orm-macros v0.6.0 (proc-macro)
├── sea-query v0.21.0
│ ├── sea-query-derive v0.2.0 (proc-macro)
├── sea-strum v0.23.0
│ └── sea-strum_macros v0.23.0 (proc-macro)
└── sea-schema v0.5.1
├── sea-orm v0.6.0 (*)
├── sea-query v0.21.0 (*)
├── sea-schema-derive v0.1.0 (proc-macro)
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 18 (18 by maintainers)
With this PR on the way, I can resume this issue 😃
yes, i’m good with it.
Hey @nahuakang, I have a plan:
On
sea-orm-cli, makesea-orm-cli migratetake a extra option:-s/--database-schema: database schema (default: DATABASE_SCHEMA specified in ENV)The db schema will be passed to
MigratorTraitmethods where it’s updated to take anyConnectionTrait(a new trait defined insea-orm-migrationnot the same assea_orm:: ConnectionTrait).On
sea-orm-migration:We have a new
ConnectionTraitwhere it has two methods:get_connection() -> &DbConnget_schema_name() -> Option<String>Implements
ConnectionTraitfor&DbConn(for backward compatibility) andMigrationConnectionAnd we need a new struct, let say
MigrationConnection, to hold the connection and schema name.Then, we modify the behaviour of public API of
MigratorTrait:install: setupseaql_migrationstable on the corresponding schemaup: apply migration scripts in the corresponding schemadown: rollback migration scripts in the corresponding schemareset: rollback all migration scripts in the corresponding schemafresh: drop all tables in the corresponding schema then apply all migration scriptsrefresh: rollback all migration scripts in the corresponding schema then reapplying allSchemaManagerwill store the&ConnectionTraitinstead of&DbConn. And all thecreate_*anddrop_*statements is now taking SeaQuery statements that properly quantify table name withTableRef, PR https://github.com/SeaQL/sea-query/pull/385. Then, we can override theTableRefinside each statement and prefix it all with the schema name provided byConnectionTrait.Good point! I think we need to update these statement to quantify the schema name
For PostgreSQL type statement, it actually supports schema name. But we didn’t implement it in SeaQuery https://www.postgresql.org/docs/current/sql-createtype.html
Hey @nahuakang, sorry for the delay. Thanks for the investigations!
Correct, and
DATABASE_SCHEMAwill only be used when the connect is pointing to PostgreSQL.Take this as reference, which inject schema name for SeaORM entity https://github.com/SeaQL/sea-orm/blob/3f90c094079501211e88ea2111ce8f2473493bdf/src/entity/base_entity.rs#L31-L37
However, for migration, we’re injecting schema name into existing SeaQuery statement. Which will be performed inside methods inside
SchemaManager. https://github.com/SeaQL/sea-orm/blob/3f90c094079501211e88ea2111ce8f2473493bdf/sea-orm-migration/src/manager.rs#L37-L133E.g. Converting the
tablefield insideTableCreateStatementfromTableRef::TableintoTableRef::SchemaTableLet me know if it was unclear.
@billy1624 Some updates after digging today:
sea-orm-cli generate entitycommand actually takes care ofDATABASE_SCHEMAforpostgres.However,
sea-orm-cli migratedoes not take care ofDATABASE_SCHEMAforpostgresand it relays the command to the migrator CLI instead.So does this mean we should take care of getting the environment value for
DATABASE_SCHEMAinsea-orm-migration, such as inbuild_cliand then, as you mentioned previously, correctly inject it down in the migration operations into usages of sea_query::TableRef?Questions:
up,down, etc.) associated withMigrationTrait?@smonv Thank you 😃 I’ll claim this!
@billy1624 Thank for guiding me. I’ll follow your PR and change the migrator patch if necessary.
Hey @MattGson, PostgreSQL’s migration currently only operate on
publicschema for now. We will respectDATABASE_SCHEMAin .env file soon.