Feat: safe to insertion of rows

[sinder38]

PR Info

In spirit it is a continuation of my other PR: #2961 as I am trying to achieve the same goal.

The goal is to make Active models (or a new type) safe to insert, with the final goal of showing it on compilation. Finalising this idea seems possible, but would require changes how defaults are processed in the codebase. From what I saw they seem to be an additional optional layer that doesn't exactly reflect the schema defaults.

Currently this PR just explores the possibility of this whole feature by adding a check method for ActiveModel fields. It's own tests do not pass as id fields don't have a set default.

For the actual final implementation:
field null-ability checking on compilation would probably require a separate trait for row insertion with a separate generated struct similar to ActiveModel whose mandatory fields are defined raw and not as ActiveValue (which allows nulls). This is quite a substantial change.

New Features

• adds a .is_to_safe_insert() method for ActiveModel to check if all fields are either set, are nullable or have a default.

Breaking Changes

currently none

Changes

• add a trait to handle new checking behaviour
• add derive macros for trait implementation
• add tests for new trait

[Huliiiiii]

We already have ValidatedUpdateOne. You can add a similar ValidatedInsertOne.

[sinder38]

ValidatedUpdateOne

Okay, I will look into it

[sinder38]

I can definitely move my checking implementation to ValidatedInsertOne, but this doesn't achieve validation on compile time like a macro generated struct would. I hope compile validation is not out of scope completely.

Also I still require confirmation about how defaults work in the codebase, without it can't finish.

From what I saw they seem to be an additional optional layer that doesn't exactly reflect the schema defaults.

I would need to change how that thing works to address the primary key test case.

Furthermore, sea-orm-cli doesn't seem to extract defaults from the schema which only supports my concerns

[sinder38]

@tyt2y3 Sorry for the ping
I wanted to point a blocker before continuing work on this PR and my other ones.
Could you please clarify how defaults are handled in the codebase - specifically, whether they're the relate actual schema defaults? Without this , I risk implementing an approach that either breaks existing behaviour or needs to be reworked. Thank you for your time

[tyt2y3]

we should have the default value / expression during schema discovery, but right now codegen doesn't generate the default_expr / default_value annotations.
once we have that, then auto_increment = true, primary_key, or fields with default_expr and default_value are not required in inserts.
this information is available to the macro, as well as runtime in the ColumnDef struct