Original Motivation Behind Parameters In after_save?

[anshap1719]

Hi, I was wondering what the original motivation behind not having the ActiveModel be passed as a parameter to the after_save hook was, or if it just wasn't thought of a use case yet? The main motivation behind this question is that since these can be used to trigger side effects such as events or emails being sent out, conditionally performing that logic based on what was changed makes more sense to me. Sure there are ways to do it manually at the moment, but if there's no strong reason, I'd like to propose to add the parameter in.

I'd be happy to create a PR if needed. Thanks.

[tyt2y3]

Just to not get your idea wrong, what's your proposed change to the API? Can you post a snippet?

[anshap1719]

@tyt2y3 Now that you asked that, I realized that this is a much bigger deal than I anticipated because it will essentially be a breaking change. But here's what I was thinking at a coarse level:

async fn after_save<C>(
        &self,
        model: <Self::Entity as EntityTrait>::Model,
        db: &C,
        insert: bool,
    ) -> Result<<Self::Entity as EntityTrait>::Model, DbErr>
    where
        C: ConnectionTrait,
    {
        Ok(model)
    }

Basically having access to self param.

[tyt2y3]

Yes, I think we might be looking into adding new APIs, which others have suggested, for example on_select. But I want to gather a consensus here to make it work for everyone. Ref: #2012

[anshap1719]

@tyt2y3 Thanks for linking that. I did come accross it when trying to find if someone else had the same idea, but didn't look at it too much into the detail.