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
.env
file 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 migrate
take a extra option:-s
/--database-schema
: database schema (default: DATABASE_SCHEMA specified in ENV)The db schema will be passed to
MigratorTrait
methods where it’s updated to take anyConnectionTrait
(a new trait defined insea-orm-migration
not the same assea_orm:: ConnectionTrait
).On
sea-orm-migration
:We have a new
ConnectionTrait
where it has two methods:get_connection() -> &DbConn
get_schema_name() -> Option<String>
Implements
ConnectionTrait
for&DbConn
(for backward compatibility) andMigrationConnection
And 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_migrations
table 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 allSchemaManager
will store the&ConnectionTrait
instead 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 theTableRef
inside 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_SCHEMA
will 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
table
field insideTableCreateStatement
fromTableRef::Table
intoTableRef::SchemaTable
Let me know if it was unclear.
@billy1624 Some updates after digging today:
sea-orm-cli generate entity
command actually takes care ofDATABASE_SCHEMA
forpostgres
.However,
sea-orm-cli migrate
does not take care ofDATABASE_SCHEMA
forpostgres
and it relays the command to the migrator CLI instead.So does this mean we should take care of getting the environment value for
DATABASE_SCHEMA
insea-orm-migration
, such as inbuild_cli
and 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
public
schema for now. We will respectDATABASE_SCHEMA
in .env file soon.