sea-orm-cli generate entity emits SQL generated columns (VIRTUAL/STORED) as writable fields

[JMLX42]

Description

sea-orm-cli generate entity now emits SQL generated columns (GENERATED ALWAYS AS (...) VIRTUAL / STORED) as ordinary, writable entity fields. Earlier 2.0 release candidates omitted them entirely.

Because the emitted field carries no marker distinguishing it from a normal column, it becomes part of the derived ActiveModel. Any INSERT/UPDATE that sets the field — most commonly via model.into_active_model() (which sets every field) — sends the generated column to the database, and SQLite rejects it:

cannot INSERT into generated column "translation"
cannot UPDATE generated column "translation"

A generated column is read-only at the storage layer, so the generated entity should not expose it as a writable column. The previous behavior (skipping it) was correct for our usage.

Steps to Reproduce

1. Create a SQLite database with a virtual generated column:

   CREATE TABLE node (
       id          INTEGER PRIMARY KEY,
       x           REAL,
       y           REAL,
       z           REAL,
       translation TEXT GENERATED ALWAYS AS (json_array(x, y, z)) VIRTUAL
   );

2. Generate entities:

   sea-orm-cli generate entity -u 'sqlite://./test.sqlite' -o ./out

3. Inspect out/node.rs.

Expected Behavior

The generated column should not be exposed as a writable column. Either omit it (as earlier RCs did), or generate it in a form that is excluded from INSERT/UPDATE — e.g. apply #[sea_orm(ignore)], which is the maintainer-recommended workaround for generated columns (discussion #2420). Ideally there would be a documented, supported way to keep such a column readable while never writing it.

Actual Behavior

translation is generated as a plain, writable column:

#[sea_orm(column_type = "Text", nullable)]
pub translation: Option<String>,

It is added to the Column enum and the derived ActiveModel, so writing the model fails at the database as shown above.

Reproduces How Often

Always, for any VIRTUAL/STORED generated column on SQLite.

Workarounds

• Manually add #[sea_orm(ignore)] to each generated-column field after codegen (per discussion Possible to use generated columns with sea-orm? #2420). This stops the write, but the field is then excluded from SELECT as well (filled via Default), and the edit has to be re-applied on every regeneration since the CLI re-emits the plain column.
• Pin sea-orm-cli to 2.0.0-rc.34, which did not emit these columns.

There is no column-level exclusion flag for generate entity (only --ignore-tables), so neither workaround can be expressed through the CLI.

Suggestion

It would help to either restore skipping of generated columns by default, or add a flag / emit #[sea_orm(ignore)] (or an equivalent read-only marker) automatically for columns reported as generated by the schema discovery (PRAGMA table_xinfo exposes the hidden = 2/3 flag for VIRTUAL/STORED on SQLite).

Versions

• sea-orm / sea-orm-cli / sea-orm-migration: 2.0.0-rc.41 (regression vs 2.0.0-rc.34, which omitted these columns)
• sea-schema: 0.18.0
• sea-query: 1.0.1
• Database: SQLite
• OS: Linux

---

_{Filed by an AI agent (Claude Code, Anthropic) on behalf of, and reviewed by, a maintainer of a downstream project that hit this on a routine sea-orm-cli bump.}

[JMLX42]

Root cause

The behavior change comes from sea-schema commit b6dfdb1 (PR SeaQL/sea-schema#161, shipped in sea-schema 0.18.0, pulled in by the rc.34 → rc.41 bump).

That PR was a deliberate and correct fix for the schema-sync path: it closes #2995, where a column declared with #[sea_orm(extra = "GENERATED ALWAYS AS (...) VIRTUAL")] was re-ALTER TABLE ... ADD COLUMN-ed on every sync, because SQLite discovery used PRAGMA table_info, which does not return generated columns at all. The fix switches discovery to PRAGMA table_xinfo and skips only virtual-table internal columns:

// sea-schema/src/sqlite/def/table.rs  (get_column_info)
query.push_str("PRAGMA table_xinfo('");   // was: table_info
...
if column.is_hidden() { continue; }       // is_hidden() == ColumnVisibility::HiddenVirtual only

GeneratedVirtual / GeneratedStored are intentionally kept so sync can see them. That part should not be reverted — reverting reopens #2995.

Why generate entity regressed

generate entity consumes the same discovery through a different path, and the generated-column flag is lost on the way to codegen:

1. sea-orm-cli (generate.rs, sqlite branch) maps each discovered TableDef via TableDef::write().
2. TableDef::write() (sea-schema, table.rs) builds each ColumnDef from name/type/null/default only — it never calls .generated(...) and never skips generated columns, so the ColumnVisibility is dropped.
3. sea-orm-codegen's Column has no generated field and From<&ColumnDef> doesn't read one, so the column is emitted as an ordinary, writable field.

The result is a plain field with no marker:

#[sea_orm(column_type = "Text", nullable)]
pub pixels: Option<i32>,

It becomes part of the derived ActiveModel; any model.into_active_model() round-trip then includes it in INSERT/UPDATE and SQLite rejects it ("cannot INSERT/UPDATE a generated column").

(Note: sea-schema#161's test only asserts hidden: Visible on ordinary columns — there's no test asserting codegen output for a generated column, so a codegen-side fix doesn't regress existing tests.)

Two ways to fix

Approach A — skip generated columns in generate entity (minimal, low-risk).
Filter GeneratedVirtual/GeneratedStored columns out of the discovered TableDef before TableDef::write() in sea-orm-cli. This restores the pre-rc.34 codegen output (generated columns omitted from the entity), leaves the sync fix (#2995) untouched (different code path), and matches how generated columns are meant to be declared in the Entity-First workflow (via #[sea_orm(extra = ...)], not reverse-generated). Trade-off: the column is absent from the entity, so it can't be read through the Model.

Approach B — reverse-generate the column faithfully (larger, Entity-First-correct).
Emit the generated column with #[sea_orm(extra = "GENERATED ALWAYS AS (...) VIRTUAL")] and exclude it from writes (codegen already emits an ignore attribute for Custom types, so the machinery exists). This is the round-trip-correct output, but it's a cross-crate change: table_xinfo does not return the generation expression, so discovery must also parse sqlite_master.sql; TableDef::write() must emit ColumnDef::generated(...); and codegen needs a generated field on Column plus the read-only attribute. Postgres/MySQL would want parity.

I'm drafting a PR for Approach A now (it fixes the reported breakage in a few lines with no risk to sync); Approach B is worth tracking as the longer-term enhancement.

---

_{Investigation and write-up by an AI agent (Claude Code, Anthropic), reviewed by a maintainer of a downstream project that hit this on a routine sea-orm-cli bump.}

[Huliiiiii]

I think the proper fix is to add support for generated columns instead of relying on extra.