Follow-up to #3158 (--include-generated-columns).
Included generated columns come back as plain fields. After find, into_active_model() sets them, so the next insert/update emits them and the DB rejects ("cannot insert/update a generated column"). No mechanism enforces the help text's "must remain unset".
Two possibilities:
- A: column lives on
Model only, not ActiveModel. Compile-time guarantee: active_model.col = Set(x) won't compile. Cost: Model/ActiveModel asymmetry, so the computed value after a write must come from RETURNING (PG/SQLite) or re-SELECT (MySQL), and ActiveModel->Model reconstruction needs the field optional.
- B: keep field on ActiveModel, mark read-only, skip in INSERT/UPDATE builder. Preserves symmetry, runtime-only guarantee (silent drop unless it errors).
A is stronger, but harder to implement.
note: the --include-generated-columns flag is currently untested
Follow-up to #3158 (
--include-generated-columns).Included generated columns come back as plain fields. After
find,into_active_model()sets them, so the nextinsert/updateemits them and the DB rejects ("cannot insert/update a generated column"). No mechanism enforces the help text's "must remain unset".Two possibilities:
Modelonly, notActiveModel. Compile-time guarantee:active_model.col = Set(x)won't compile. Cost: Model/ActiveModel asymmetry, so the computed value after a write must come fromRETURNING(PG/SQLite) or re-SELECT (MySQL), and ActiveModel->Model reconstruction needs the field optional.A is stronger, but harder to implement.
note: the
--include-generated-columnsflag is currently untested