[Feature] Automatic audit function

[ilxqx]

Motivation

Many times, our table structure will have fields like: created_at, updated_at, created_by, updated_by. These fields are usually generated automatically by the ORM framework.

For example:created_at is only generated during insert, updated_at is generated during insert or update.

Proposed Solutions

Although these functions can be implemented through the Entity's Hook (ActiveModelBehavior), it is redundant to write them for each entity, and it doesn't make sense. I hope the framework can have the functionality of global hooks, and at the same time, the framework can also provide several commonly used global hooks (such as AuditableHook). Users can also customize global hooks (for example, implementing automatic auditing for created_by and updated_by).

I think this will be a powerful feature, providing more hooks will be more convenient.

Another suggestion is that there is a lack of after_get/after_query hooks in ActiveModelBehavior. This hook can implement further processing of the queried Model(For example: unified data dictionary translation for some fileds in Model.).

Current Workarounds

Hardcoding, repetitive copying

[tyt2y3]

Yes, I think after_get would be a low hanging fruit. We didn't add that initially, may be because I don't think there will be a need for it, or it might create confusion.

I think a major concern is whether we can apply the same operation to partial and custom selects. What do you think about this?

[ilxqx]

Thank you for your reply.

There is such a scenario. Suppose we have a user table: user(id, name, account, status, created_at, updated_at).

Here, the status column is a state column. Our design principle is to store values like 1 or 2 in the database, which represent enabled and disabled respectively. When we query the data from the user table through sea-orm and return it to the frontend UI for display, we need to translate the status field by translating 1 as enabled and 2 as disabled.

This translation operation is just one example of similar cases. Moreover, this translation operation cannot be hard-coded into select because it is dynamic and stored in the database. During translation, it dynamically queries the database based on relevant identifiers to obtain translated content corresponding to 1 or 2. Therefore, this operation is suitable for hooks like after_query/after_get because it repeats almost everywhere globally.

[ilxqx]

Of course, the user's status is just a simple example. Perhaps you might think that it can be hard-coded because enabling and disabling are basically determined in the future.

But what about the user's type? Suppose the user has a type field with values of 1 and 2, representing unauthenticated user and regular user respectively.

What if a new type, 3, is added in the future to represent member user? It definitely won't work if we continue to hard-code it.

[tyt2y3]

If we only focus on your use case, I'd think the "after select" operation can be per column, do you have a need for it to access all fields of the model in one call?

I am thinking a definition of:

fn after_select(column: E::Column, value: Value) -> Value;

// or ?

fn after_select(&mut E::Model);

[ilxqx]

I think:

fn after_select(&mut E::Model);

would be better.

The reasons are as follows:

More customized modifications can be made to the model.

Scenario 1: The modification of a certain field depends on several other fields in the model.
Scenario 2:
Assuming model definition:

#[derive(
    Clone, Debug, PartialEq, Eq, DeriveEntityModel, Serialize, Deserialize, DataDictionaryTranslate,
)]
#[sea_orm(table_name = "sys_user")]
#[serde(rename_all = "camelCase")]
pub struct Model {
    #[sea_orm(primary_key, auto_increment = false)]
    pub id: String,
    // ... other omitted fields
    #[translate(name = "user_status", field = "status_name")]
    pub status: SwitchStatus,
    #[sea_orm(ignore)]
    pub status_name: Option<String>,
}

For the field status_name, it does not exist in the database table itself. It is a virtual field only used to store the translation result of the field status.

If fn after_select(&mut E::Model); is used, similar pseudocode would be as follows:

fn after_select(model &mut E::Model) {
    // 1. Directly call the method derived from the custom `Derive` macro `DataDictionaryTranslate`.
    model.translate();

    // 2. Or manually translate
    model.status_name = translate_data_dictionary("user_status", model.status);
}

[tyt2y3]

I do agree that adding a new method to the trait ActiveModelBehaviour makes the most sense.

I was looking into the implementation strategy, but realized quite a bit of plumbing work needs to be done to carry the ActiveModelBehaviour type along the execution pipeline, until after FromQueryResult. Basically we'd want the function to be applied after M::from_query_result (in Selector*). We need the A: ActiveModelBehaviour there.

It would be easier if we attach the behaviour onto FromQueryResult, but then it'd require some macro tricks.

[ilxqx]

Thank you.

I am a Java programmer and only a beginner in Rust. I apologize that I cannot thoroughly understand the sea-orm source code in a short period of time, so I cannot provide some reasonable implementation strategy suggestions.

[tyt2y3]

Okay, have another idea. If we allow ourselves to Box<dyn Fn(T)> it can make the task easier.