Skip to content

Conversation

@Expurple
Copy link
Member

@Expurple Expurple commented Aug 27, 2025

See #954.

I think, this version is more correct and easier to understand (regarding case-sensitivity, [] handling, etc). The summary is in the changelog, as always

@Expurple
Copy link
Member Author

Expurple commented Aug 27, 2025

But now I'm stuck with this failing ExprTrait::as_enum doctest. I've read this explanation of AsEnum and I understand the need to separate quoted (case-sensitive) and unquoted (case-insensitive) casts, but I still don't understand why as_enum needs to do a cast only on Postgres and do nothing on MySQL and SQLite. This behavior is undocumented, seems very weird, and requires that special AsEnum node which I tried to remove.

Is this something that SeaORM needs? Perhaps, SeaORM itself should apply this DB-specific logic? I find it weird that I can explicitly call my_val.as_enum(my_type) (a seemingly low-level query builder method) and get no cast at all, depending on the database.

@Expurple Expurple requested review from Huliiiiii and tyt2y3 August 27, 2025 12:23
@tyt2y3
Copy link
Member

tyt2y3 commented Aug 29, 2025

To further explain, in Postgres a enum is a (user-defined) type that's created by the CREATE TYPE statement.
MySQL is more relaxed, it's basically a string with some constraints.
In SQLite it is just a string.
The problem is when doing inserts for example, we can do INSERT INTO my_table VALUES ('my_enum_variant') in MySQL / SQLite, but has to cast it explicitly in Postgres INSERT INTO my_table VALUES (CAST 'my_enum_variant' as "my_enum").

The problem in SeaORM is that the frontend (query building stage) doesn't know about the backend yet. It's only known when we call exec, and I'd rather not walk the AST again and tweak the nodes.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants