Update ActiveModelBehavior API allowing custom validation logic

[billy1624]

Issue raised by @MuhannadAlrusayni, thank you so much for the suggestions!

Looking at ActiveModelBehavior I wounder what it's used for ? is it for controlling how the model get updated ? but these methods doesn't return Result<..>.
I have some business logic that restrict how my model get updated/inserted and I thought that ActiveModelBehavior would help me here to do so, other wise I would need not to expose my account::Entity struct since SeaORM doesn't provide a way to restrict update/insert to match my business logic.

let me tell you my use case, it is that I plan to make my backend into group of crates that's independents of each other, and I want each crates to be targeting a specific domain problem, so let's say I have crate called users, it's used to manage users accounts, sessions, rules. and I have another crate called stroes.

stroes crate depend on users, since each store should belong to a User.

the problem is that users crate encapsulate it's own data and their business logic, and when I use SeaORM I have to expose user::Entity to other crates such as stores, but since SeaORM doesn't provide a way to inject my business logic validation I cannot expose user::Entity to other crates at all.
I am not sure if explained my problem enough.

[billy1624]

Basically each Entity should be able to perform their own validation logic defined inside the entity file. Rather than relaying on the user to perform the validation. However, SeaORM current didn't offer any way to perform validation in Entity level.

[MuhannadAlrusayni]

I also think there is a few missing methods:

// change 1)
// change the return type to be `Result<T, E>`

// change 2)
// add missing method:
fn after_delete(self) -> Result<Self, Error> { ... }

// change 1)
// we need to change the *_save() to indicate if this is inserting or updating entities:
fn after_save(self, is_insert: bool) -> Result<Self, Error> { ... }
fn before_save(self, is_insert: bool) -> Result<Self, Error> { ... }

// or we add these new methods instead changing *_save() methods.
fn before_insert(self) -> Result<Self, Error> { ... }
fn after_insert(self) -> Result<Self, Error> { ... }

here is another changes that we need to discuss further:

1. what if a after_save() failed with Err(..) ? should we roll back the changes made into the database ?
2. should we pass a database connection to these methods as well ? I can think of uses cases that needs to check after/before (e.g. checking if email already exists) inserting an entity records.

[billy1624]

// change the return type to be `Result<T, E>`

Yes!

fn after_delete(self) -> Result<Self, Error> { ... }

Agree

fn after_save(self, is_insert: bool) -> Result<Self, Error> { ... }
fn before_save(self, is_insert: bool) -> Result<Self, Error> { ... }

I think this is reasonable, handle insert / update in single *_save method and with an is_insert flag supplied to it.

[billy1624]

1. what if a after_save() failed with Err(..) ? should we roll back the changes made into the database ?

I think we should if we are executing this save in transaction.

2. should we pass a database connection to these methods as well ? I can think of uses cases that needs to check after/before (e.g. checking if email already exists) inserting an entity records.

Good suggestions!