InsertModel and UpdateModel

[tyt2y3]

Following up on #97 #94 #96

I have a rough idea:

1. to annotate the attributes of Entity's Model, where each attribute has three possible 'requirements': auto_identity (auto generated primary key), required (implied and thus can be omitted) and optional

2. from there, we can derive two more structs, InsertModel and UpdateModel
   For InsertModel, auto_identity will be omitted, and required fields will be wrapped with RequiredValue, which must be Set. Optional fields will be wrapped with ActiveValue, which can be Set or Unset.
   For UpdateModel, auto_identity will be wrapped with RequiredValue, while all other fields will be wrapped with ActiveValue (thus are optional)

3. change the Insert and Update API such that they accept IntoInsertModel and IntoUpdateModel respectively. ActiveModel can still be converted automatically into InsertModel and UpdateModel, but will panic if the 'requirements' mismatch

[tqwewe]

I like what you've desribed here... looks promising.

I think this could be related to: #105 - perhaps a refactor to the API can be considered.

[tyt2y3]

After #105, I think it will provide us some compile-time info to work with, i.e. the default_value and default_expr tags.

As such, we'd be able to generate two extra models InsertModel, UpdateModel along with ActiveModel, under the following rules:
For insert model, skip the 'auto_increment primary_key' columns. Fields without default will be wrapped with RequiredValue, ActiveValue otherwise.
For update model, the 'primary_key' columns will be wrapped with RequiredValue while all other fields will be wrapped with ActiveValue

[billy1624]

Btw... why we cant set an value for primary key with auto_increment during insert?

[tqwewe]

It is possible to specify the primary key even if a primary key column is auto_increment, but I can't imagine many situations where that'd be useful to anyone.

I'm also thinking that the update and insert models can be used with async-graphql under a feature flag in the future, and you typically wouldn't allow the primary key to be set when inserting a new item. But for the async-graphql case, it could just add #[graphql(skip)] to the primary key on the insert model if it were to be kept.

[nicoulaj]

Please also note all GENERATED ALWAYS columns should be excluded from insert/update queries or use DEFAULT as value. See for example Postgres or MySQL.

A generated column cannot be written to directly. In INSERT or UPDATE commands, a value cannot be specified for a generated column, but the keyword DEFAULT may be specified.

Maybe those could be directly excluded for InsertModel/UpdateModel ? In ActiveModel, maybe ActiveValue could be split into ReadableActiveValue + WritableActiveValue for these columns ?

[tyt2y3]

Thanks @nicoulaj I think you raised a good point not yet considered.