feat: Extend DeriveIntoActiveModel

[sinder38]

PR Info

• Closes Extend DeriveIntoActiveModel to support settable and default-able values #2960

New Features

• Add simple documentation for DeriveIntoActiveModel
• Add field-level attributes to:
  • Skip mapping a field to the ActiveModel.
  • Define a custom default value or default function for a field.
• Introduce container-level attributes to:
  • Define fallback values for omitted fields.
  • Enforce exhaustive coverage of all ActiveModel fields.
• test spam

Look at the cool table below:

Before this PR

Input Value	Struct Field	Result in ActiveModel
Not provided	Field not declared	NotSet
Provided	Field declared	Set(value)

After this PR

Input Value	Required Action	Result in ActiveModel
Not provided but must be set	Add #[sea_orm(set(field = "..."))]	Set(expr)
Sometimes provided	Use Option<T> + #[sea_orm(default(expr))]	Some(v) -> Set(v) None -> Set(expr)
Provided directly	Declare field normally	Set(value)
Not provided and not required	Omit field	NotSet
Provided but not needed	Add `#[sea_orm(ignore)]	NotSet/ no effect

Alternative solution:

These same features could be implemented as a separate derive macro with its own trait to indicate that the struct is safe to insert.

Showcase:

Computed defaults, constants, and expressions

const SYSTEM_USER_ID: i32 = 0;
#[derive(DeriveIntoActiveModel)]
#[sea_orm(
    active_model = "post::ActiveModel",
    set(updated_at = "chrono::Utc::now()"),
    set(version = "1")
)]
struct CreatePost {
    title: String,
    content: String,
    #[sea_orm(default = "chrono::Utc::now()")]
    published_at: Option<chrono::DateTime<chrono::Utc>>,
    #[sea_orm(default = "SYSTEM_USER_ID")]
    author_id: Option<i32>,
}

• set(...) supports arbitrary Rust expressions (functions, constants, literals).
• #[sea_orm(default = "...")] provides fallback expressions for Option<T> fields.
• Multiple set(...) attributes are supported and merged.

Exhaustive mode with field control

#[derive(DeriveIntoActiveModel)]
#[sea_orm(
    active_model = "account::ActiveModel",
    exhaustive,
    set(updated_at = "chrono::Utc::now()")
)]
struct UpdateAccount {
    id: i32,
    #[sea_orm(default = "false")]
    disabled: Option<bool>,
    #[sea_orm(ignore)]
    audit_log: String,
}

• exhaustive removes ..Default::default(), forcing explicit coverage of all ActiveModel fields.
• ignore cleanly excludes DTO-only fields.
• default and set compose cleanly under exhaustive mode.

Breaking Changes

Should be fine, because it's backward compatible and changed code is under pub(super).

Changes

• Add support for field-level #[sea_orm(default = "...")] to provide fallback values for Option<T> fields when None.
• Add support for field-level #[sea_orm(skip)] / #[sea_orm(ignore)] to exclude fields from IntoActiveModel generation.
• Add container-level #[sea_orm(set(...))] to explicitly set ActiveModel fields with custom expressions.
• Add container-level #[sea_orm(active_model = "...")] parsing improvements.
• Introduce IntoActiveModelField enum to support normal and default-backed fields.
• Extend meta parsing utilities with get_as_kv_with_ident to support identifier–expression pairs.
• Add basic documentation improvements for DeriveIntoActiveModel.
• Some tests for good measure

[sinder38]

Set as draft until the maintainers decide on the desired design.

[Huliiiiii]

I prefer MetaList (default(expr)) over MetaNameValue (default = "expr").

But sometimes it makes the semantics ambiguous, e.g. default(false).

[Huliiiiii]

By the way, for such a complex case, wouldn’t directly implementing IntoActiveModel be simpler and clearer?”

[sinder38]

I prefer MetaList ...

Yee, I also think MetaNameValue is clearer, but I’m not opposed to a having MetaList implementation option.

By the way, for such a complex case, wouldn’t directly implementing IntoActiveModel be simpler and clearer?”

Regarding the more complex cases: honestly, I’m stuck between a rock and a hard place. Either I write custom implementations for each of the like 50 structs I have, which would roughly double the amount of code or I implement these macros.

In the end, macros it is because, in my experience, refactoring many manual implementations is significantly more painful than maintaining macro-based solution.

[Huliiiiii]

Because all macros share #[sea_orm(...)], I’d recommend using #[sea_orm(into_active_model(...))] or #[into_active_model(...)] to avoid conflicts. (Although it’s an uncommon usage, it can also make the semantics a bit clearer.)

@tyt2y3, thoughts?

[tyt2y3]

I think it looks good and well thought out!

[sinder38]

should I mark as ready or do you want changes like MetaList, renaming to into_active_model , or more tests or smt else

[sinder38]

I think it would be better to change variable names and comments once the design and features are finalised.
code before me was undocumented :v . The comments in the code were mostly for me to stop getting lost and forgetful

[tyt2y3]

I think the design is good, only consideration is the name for the set attribute. it's short and can mean many things, but there may not be a better name

[Huliiiiii]

Does set accept multiple values?
For example:

set(updated_at = chrono::Utc::now(), version = "1")

I think we could support a serde-like #[sea_orm(default)] attribute to let fields automatically use Set(Default::default()) as the default.

[sinder38]

Yes, it supports both ways of adding multiple set.
Bare #[sea_orm(default)] makes sense, here it is added.

[kvpavel64]

Thanks a ton for your awesome contribution to the community!