sharing experience from loco.rs

[jondot]

Hi @carllerche
This is an exciting project coming from tokio.
I've been building loco.rs which I hope fills in the "productivity" part for Rust (referring to that section in your blog post).
We're using SeaORM, which is stable and feature rich, and serves us well so far.

Here are some things I looked for when I evaluated SeaORM (against Diesel, sqlx-macros, etc.), I hope to offer (not to push) some insight for Toasty:

• Ability to extend a codegen'd entity, via extension or composition:

// let me implement my own finders, and get them via the main entity
User::some_custom_selector(..)

// let me extend logic onto my fetched entities to keep logic tied to data
let user = User.find(..)
if user.has_billing() {
   //...
}

• Lifecycle that is ownership-happy. SeaORM DB connection is cheaply cloned and so this allows for a "downward-only" request flow, where end users of the framework don't care (or aren't aware) of any ownership issues or considerations upstream
• Migrations-as-code, additive. If you look around live Rust / Axum / Sqlx etc. codebases you'll see many people use SQL file migrations, which is not the best for this scenario. People choose an ORM and then get screwed over by specifics of a specific-database SQL DDL language, which live in their migrations.
• Auto migration ("syncing" a schema, as well as versioned, additive migrations)

While there are many more bits and pieces (like relationships, lazy loading, etc -- which I'm sure you'll get right as do all ORMs eventually), I think these are the pivotal ones that can really affect an ORM's design.

Hope this help shape Toasty's direction for the better, and good luck!

[codegod100]

+1 on the ownership issue. Multiple people are running into #13. Consumers of API shouldn't need to worry about your library's lifetimes

[Chaoses-Ib]

Auto migration ("syncing" a schema, as well as versioned, additive migrations)

There are several crates for this thing, maybe Toasty can integrate or reference them:

• Renovate: Renovate is a CLI tool to help you to work on Postgres SQL migration easily.
• postgres_migrator: A postgres migration generator and runner that uses raw declarative sql.
• Models: A tool for automated migrations for PostgreSQL, SQLite and MySQL.

[carllerche]

Thanks for taking the time to write this up. Feedback is constructive at this point as Toasty's API is still very easy to change and iterate on.

Ability to extend a codegen'd entity, via extension or composition:

Since plain-old structs are generated, you should be able to add impl blocks on them in your app. Both your examples should be as easy as:

impl User {
    pub fn some_custom_selector(....) -> ... { ... }

    pub fn has_billing(&self) -> bool { ... }
}

Lifecycle that is ownership-happy.

Definitely, and that is the goal. There was an issue w/ lifetimes earlier (referenced above) but that should be fixed.

Migrations

I do want a really solid migration story. That said, I haven't yet really dug into it. I'm definietly open to suggestions on that front.