From DeriveIntoActiveModel to a Rust MapStruct: should SeaORM add DeriveIntoVo or incubate a dedicated mapper?

[littlehBinBin]

From DeriveIntoActiveModel to a Rust MapStruct: should SeaORM add DeriveIntoVo or incubate a dedicated mapper?

Summary

SeaORM already provides:

• DeriveIntoActiveModel for mapping input DTOs to ActiveModel
• IntoActiveModel for mapping an existing Entity::Model to ActiveModel
• FromQueryResult for mapping query results directly into custom structs

However, there is no built-in way to map an existing Entity::Model to an application-level View DTO or VO.

A common pattern is:

let user = users::Entity::find_by_id(id)
    .one(&db)
    .await?
    .ok_or_else(|| AppError::NotFound)?;

let vo = UserVo {
    id: user.id,
    username: user.username,
    email: user.email,
    nickname: user.nickname,
    avatar_url: user.avatar_url,
};

This is repetitive when a project has many models and many view DTOs.

Narrow Feature Request

Add a narrow, optional derive macro such as DeriveIntoVo or DeriveFromModel:

#[derive(DeriveIntoVo, Serialize)]
#[sea_orm(from_model = "users::Model")]
pub struct UserVo {
    pub id: String,
    pub username: String,
    pub email: String,
    pub nickname: String,
    pub avatar_url: String,
}

It could generate:

impl From<users::Model> for UserVo {
    fn from(model: users::Model) -> Self {
        Self {
            id: model.id,
            username: model.username,
            email: model.email,
            nickname: model.nickname,
            avatar_url: model.avatar_url,
        }
    }
}

Desired Scope

This is not a request to turn SeaORM into MapStruct.

A useful first version could stay intentionally small:

• same-name fields
• target struct may contain a subset of source fields
• field rename
• skip and default fields if needed
• no relation loading
• no nested conversions initially
• no business logic
• no async behavior

For example:

#[derive(DeriveIntoVo, Serialize)]
#[sea_orm(from_model = "users::Model")]
pub struct UserVo {
    pub id: String,
    pub username: String,
    pub email: String,

    #[sea_orm(rename = "avatar_url")]
    pub avatar: String,
}

One important safety property would be that only fields declared on the target VO are mapped. This avoids accidentally exposing fields such as password, tenant_id, or is_super_admin.

Existing Alternatives

Today users can:

1. Write impl From<Entity::Model> manually.
2. Use a third-party mapping crate such as o2o.
3. Use FromQueryResult and query directly into a VO when the data comes from the database.

But FromQueryResult does not help when the application already has an Entity::Model in memory.

Broader Idea: A Full Rust MapStruct-like Crate

While the immediate request is for a narrow Model -> View DTO derive, I also want to raise a broader question.

Would the SeaORM team consider a more complete, Rust-native mapping ecosystem, similar in spirit to Java MapStruct?

I understand that a full mapper should probably not become part of SeaORM core. SeaORM should remain focused on entities, queries, relations, and persistence. A separate crate or repository may be a better fit.

However, I think there is real development value in a well-maintained mapping crate that supports:

• struct-to-struct mapping
• From, Into, TryFrom, and TryInto
• field rename
• skip and default fields
• Option handling
• nested structs
• Vec, HashMap, and other collections
• enum mapping
• fallible field conversions
• custom conversion functions
• compile-time errors with useful diagnostics
• no runtime reflection
• support for SeaORM Model, ActiveModel, DTOs, commands, and VOs
• optional integrations with Axum, Serde, and validation crates

The most important point is trust and long-term maintenance.

There are already some community crates such as o2o, structural-convert, model-mapper, and magic_map, but the ecosystem is fragmented and many users are not sure which one will be maintained long term.

If a trusted team maintained a dedicated mapper crate, I believe it could remove a large amount of repetitive code across Rust backend projects. It would not need to become part of SeaORM core, but a SeaQL-adjacent or SeaQL-endorsed crate could be very valuable.

Possible paths:

1. Keep SeaORM core focused and only accept a narrow DeriveIntoVo if it is considered in scope.
2. Create a separate crate, for example something like sea-orm-mapper or a more general rust-mapper, maintained as a SeaQL-adjacent project.
3. Incubate or endorse an existing community crate instead of starting from scratch.
4. If the team does not want to own it, document recommended crates and patterns clearly.

I think the narrow derivation and the full mapping crate are separate decisions.

The narrow feature could solve the common SeaORM pain point. A separate mapper crate could solve the broader ecosystem problem without increasing SeaORM's maintenance burden.

Questions

1. Is Model -> View DTO considered in scope for SeaORM?
2. If not, would the team prefer this to remain a third-party crate or a documentation example?
3. Would a narrow derive macro for simple subset and rename field mapping be acceptable?
4. Would the SeaORM team consider creating or incubating a separate mapper crate?
5. If the team does not want to own it, would SeaQL be open to endorsing or recommending a well-maintained community solution?
6. Is there any existing design reason why these features should not live in or near SeaORM?

I searched existing issues and discussions and could not find an existing proposal specifically for Model -> View DTO. I also saw that DeriveIntoActiveModel has already been extended in related issue #2960, so there may be some precedent for improving derive-based mapping.

I would be happy to help clarify the design or contribute a narrow implementation if the team considers this in scope.

[Huliiiiii]

https://github.com/SeaQL/.github/blob/master/AI_POLICY.md
And we already have DerivePartialModel.

[littlehBinBin]

Thank you for your hard work maintaining SeaORM. It’s an amazing and powerful library!

Thanks for the clarification, and I'll follow the AI policy.

I understand that DerivePartialModel covers the query path where a partial model is selected directly from the database. That is useful.

The remaining gap I am running into is DTO -> ActiveModel when the DTO field names intentionally differ from the entity or column names.

For example, suppose the DTO field is named nickname_rd, but the entity field and database column are named nickname. Today I have to either ignore the DTO field and set nickname manually, or drop DeriveIntoActiveModel and write a manual conversion.

The current workaround looks like this:

#[derive(DeriveIntoActiveModel)]
#[sea_orm(active_model = "users::ActiveModel")]
pub struct RegisterReq {
    pub username: String,
    pub email: String,
    pub password: String,

    #[sea_orm(skip)]
    pub nickname_rd: String,
}

Then in the service:

let mut model = register_req.into_active_model();
model.nickname = Set(register_req.nickname_rd);

That is exactly the kind of boilerplate I was hoping to avoid. It becomes more painful when database names or API field names change over time, because every rename can force a manual From or IntoActiveModel implementation.

Would the maintainers consider adding a narrow field-level rename or alias attribute to DeriveIntoActiveModel? For example:

#[derive(DeriveIntoActiveModel)]
#[sea_orm(active_model = "users::ActiveModel")]
pub struct RegisterReq {
    pub username: String,
    pub email: String,
    pub password: String,

    #[sea_orm(rename = "nickname")]
    pub nickname_rd: String,
}

Or, if alias is preferred:

#[derive(DeriveIntoActiveModel)]
#[sea_orm(active_model = "users::ActiveModel")]
pub struct RegisterReq {
    pub username: String,
    pub email: String,
    pub password: String,

    #[sea_orm(alias = "nickname")]
    pub nickname_rd: String,
}

The generated code could map:

users::ActiveModel {
    username: req.username.into_active_value().into(),
    email: req.email.into_active_value().into(),
    password: req.password.into_active_value().into(),
    nickname: req.nickname_rd.into_active_value().into(),
    ..Default::default()
}

I used rename or alias here because they feel more natural for DTO -> ActiveModel mapping. If both names are supported, they could be treated as aliases for the same behavior, similar to ignore and skip, but one primary name would probably be enough.

This would be a very small macro-level extension, not a full mapping framework. It would mainly help when DTO naming and entity naming diverge, while still keeping the field mapping explicit.

Would this be considered in scope for DeriveIntoActiveModel? If not, what direction would you recommend for this case?

[Huliiiiii]

Solved by #3233

[littlehBinBin]

牛逼！thanks！

[littlehBinBin]

Hi, I'm not very familiar with your release cadence. Could you let me know if this commit is expected to be included in the next patch release, or is it still uncertain?

[Huliiiiii]

发布时间不确定，暂时可以 patch 用 github 上的版本