SeaQL
sea-orm-cli generate entity fails with cross-referenced types from other schemas
Description
Entity Generation Fails with Cross-Schema Type References
Steps to Reproduce
- Create a database with the following schema:
-- Create enum type in public schema
CREATE TYPE public.status_type AS ENUM ('active', 'inactive', 'pending');
-- Create custom schema
CREATE SCHEMA custom_schema;
-- Create table in custom schema that uses the enum from public schema
CREATE TABLE custom_schema.items (
id SERIAL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
status public.status_type NOT NULL
);
- Run sea-orm-cli to generate entities for the public schema (works fine):
sea-orm-cli generate entity \
-u "postgres://user:pass@localhost/dbname" \
-o "./entities/public" \
--database-schema public
- Run sea-orm-cli to generate entities for the custom schema (fails):
sea-orm-cli generate entity \
-u "postgres://user:pass@localhost/dbname" \
-o "./entities/custom" \
--database-schema custom_schema
Error Message
error returned from database: type "status_type" does not exist
Expected Behavior
The CLI should correctly recognize that status_type exists in the public schema and generate proper imports or references to it when generating entities for the custom schema.
Ideally we could pass a comma separated list into the --database-schema arg.
Actual Behavior
- The CLI fails to recognize types from other schemas, causing generation to fail with a "type does not exist" error.
- When the enum is moved out of the public statement. The reflection fails to prepend the schema to the name field in the sea_orm attribute macro.
Reproduces How Often
Always
Workarounds
Duplicate the enum across schemas gets passed the reflection, but I've run into issues with insertion.
Versions
sea-orm: 1.1.4 postgres: 16
Hello @Huliiiiii is this being worked on or can I attempt to fix and send in a PR?
@kayandra
When --database-schema is set, search_path is set to the specified schema.
When reflecting column types, we used the type name without the schema, which caused this error.
A possible fix is to use the fully qualified type name with the schema instead of the bare type name.
