MySQL enum to Rust enum

[John_Nagle]

What's the idiomatic way to convert an SQL enum to a Rust enum?
Searches show the long way, a match on string name, and the use of a derive macro in "sqlx", an async crate. Is that macro available without "async"?

[khimru]

@John_Nagle

What's the idiomatic way to convert an SQL enum to a Rust enum?

The big question is: how do you imagine that would work? Time travel? Magic? MySQL enums are only know at runtime and Rust enums have to be known before that, at compile time.

@John_Nagle

Searches show the long way, a match on string name, and the use of a derive macro in "sqlx", an async crate.

Sqlx solves the “we couldn't do that withput magic or time-travel” issue by providing connection to your SQL database to procmacro crate. Then “runtime” for that crate becomes “before compile-time for main program” and things work.

@John_Nagle

Is that macro available without "async"?

That's pointless question: you need something to plug that derive into… if not SQLx (which is an async crate)… then what?

[John_Nagle]

@khimru

The big question is: how do you imagine that would work? Time travel? Magic? MySQL enums are only know at runtime and Rust enums have to be known before that, at compile time.

Probably with a derive macro for enums that grinds out boilerplate code like

pub fn new_from_string(s: &str) -> Result<Self, Error> {
    match s {
        "SculptTexture" => Ok(Self::SculptTexture),
        "Mesh" => Ok(Self::Mesh),
        "BaseTexture" => Ok(Self::BaseTexture),
        "EmissiveTexture" => Ok(Self::EmissiveTexture),
        _ => Err(anyhow!("Invalid TileAssetType: {}", s))
    }
}

[khimru]

That's answer to entirely different question. The question is not about what do you want to see on the output side, but about where input side would come from.

What was input of your imaginary system? Where these SculptTexture or EmissiveTexture character sequences were pulled? Were they magically conjured from the thin air or what have happened here?

You talk about MySQL enums, but these are not accessible to the compiler without some trick…

[John_Nagle]

The idea is that you write the Rust definition of the enum to match the SQL definition of the enum, and something cranks out the boilerplate code to convert to and from the String representation that MySQL uses. It seems a basic function that ought to be supported.

[simonbuchan]

You're probably looking for

strum

[khimru]

@John_Nagle

The idea is that you write the Rust definition of the enum to match the SQL definition of the enum

Yes, how could compiler ever do that? “SQL definition of enum” lives somewhere in the database… how is compiler supposed to access it?

@John_Nagle

and something cranks out the boilerplate code to convert to and from the String representation that MySQL uses.

“Cranks out the boilerplate code” using… what exactly?

@John_Nagle

It seems a basic function that ought to be supported.

Maybe… if we may invent the way to define it. Because so far you still haven't explained where the names that you want to see in the output would come from, on the input.

Reading MySQL database is not “basic functionality” of Rust compiler…

[chung]

Sea orm does have enum conversion between rust and the database. Not sure if this is what you are looking for.

MySQL​ - ActiveEnum | SeaORM 🐚 An async & dynamic ORM for Rust

[khimru]

SeaORM uses SQLx inside and provides the same answer to the answer to the “magical” question about how MySQL enum may ever be accessed by compiler.

This may or may not be what @John_Nagle planned, we would never know.

If one simply wants to write manual declaration of enum that matches what SQL database would [supposedly] have then strum is good answer.

If one wants to have a procmacro that would actually talk to SQL server during compilation then SQLx and thus SeaORM become viable — but then you are tied to some concrete SQL runtime, by necessity.

[John_Nagle]

Agree that Strum is a good solution.

Part of the confusion is that ENUM is not standard SQL. It's in MySQL and Postgres, but not the SQL standard. The Rust "mysql" crate has a few references to it, but not explicit support for mapping MySQL enums to Rust enums.