Use build script to generate models

[tqwewe]

From my experience, creating models with SeaORM seems like you have to map each column to your model 1:1 exactly, and making a mistake is something that would not be picked up at compile time.

I had previously mentioned an idea about the DeriveModel macro validating the struct at compile time, but after using the tonic library, it seems like there may be a better approach.

My suggestion:
Create a library sea-orm-build, which is to be used in a build.rs file as a build script, and generates models and relationships from a database connection.

For example:

// build.rs
fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Generate models from the `users` and `comments` tables.
    sea_orm_build::generate_models("postgres://user:pass@domain:5432", &["users", "comments"])?;
    Ok(())
}

This would move all the models and relationships into a generated models.rs file which can be referenced by the app.

// main.rs
mod user {
    sea_orm_build::include_models!("users");
}

mod comment {
    sea_orm_build::include_models!("comments");
}

use user;
user::Entity as User;

#[tokio_main]
async fn main() {
    let db = ...;
    
    let users: Vec<user::Model> = User::find().all(db).await?;
}

Benefits:

• Your models will be a 1:1 match of your database, elimitating runtime errors due to model mismatches
• Removes boilerplate and need for manual models with all the dervies attached

Cons:

• If a database changes suddenly, your project may not compile until you update it accordingly
• Cannot manually modify a model

See tonic for an example of using the build.rs file to generate code: https://github.com/hyperium/tonic/tree/master/tonic-build

[tyt2y3]

I checked. Certainly a good idea!

But I do not agree on the bit where we have to squash everything into one file, is there a benefit of doing so?

[tqwewe]

Maybe you can do examples.

Hmm I did some examples in my original post and my comment above. Looking into the tonic-build library would also give some insight as the approach is very similar.

[tyt2y3]

Cool. I get it now.

I think there are cases dev would like to modify the entity files by hand, or at least being able to look at them and allow IDE support.

I think the better workflow would use that as a build time check: if the database columns mismatch, it won't compile.

Optionally, the build script can generate entity files into the /src directory of the codebase, so devs would simply inspect the changes, and commit them if they make sense.

[tqwewe]

I think there are cases dev would like to modify the entity files by hand, or at least being able to look at them and allow IDE support.

You can inspect the file if you build your project and open it in /target/release/build/..., but cannot edit it.

Optionally, the build script can generate entity files into the /src directory of the codebase, so devs would simply inspect the changes, and commit them if they make sense.

Sadly build scripts cannot generate code in /src I believe. Files can only be generated in the OUT_DIR env var (which is usually /target/release/build/...).

I think the better workflow would use that as a build time check: if the database columns mismatch, it won't compile.

The build script does not have access to the items exported by the app. So I don't think validation in the build.rs file is possible either.

Also, if the build script only validates as you suggest, then what possible changes could devs make to the struct themsevles which would keep the validity of the struct? The only one I can think of is adding additional derives to the structs, but not changing the field names or types.

If you are validating a struct which could only have one possible valid definition, wouldn't that be the perfect use case for code generation?

[tyt2y3]

It is certainly possible, just a bad practice I guess. That say, then it presents a completely different workflow.

I think the major consideration is IDE support. It'd be a bad experience if no symbols are offered (am I wrong on this?)

Any other possibilities?

[tqwewe]

It is certainly possible, just a bad practice I guess. That say, then it presents a completely different workflow.

The nice thing about it, is that it's a new feature which can be there if people want it, otherwise they can define their models how they please. And if they have 50 tables, but 2 of them need to be custom for some reason, they can just generate the 48, and define the last 2 themselves as you normally do.

Eg:

sea_orm_build::generate_models(
    "postgres://user:pass@domain:5432",
    &[
        "table1",
        "table2",
        "table3",
        // ....
    ]
)?;

Which is great for large projects with many teams touching the database.

I think the major consideration is IDE support. It'd be a bad experience if no symbols are offered (am I wrong on this?)

From experience with tonic, sadly the IDE does seem to have issues having autocomplete for this approach.. but it may be fixed in the future. I will do some research to see if there's an easy fix for this.

Edit: it seems like for Rust analyser, you just need to enable the "Run Build Scripts" option.

Any other possibilities?

I am open to suggestions! But I think this feature is definitely unique in ORM's with Rust, and something that may appeal to many people.

[tqwewe]

PR created:
#241