`InsertModel` and `UpdateModel`

[seaql]

`InsertModel` and `UpdateModel`

[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.