generate model/crud writes a migration missing the model's declared fields (500 on first write)

[andrevanzuydam]

Found while validating the llms.txt AI-bootstrap flow end to end (CLI 3.8.58, tina4-python 3.13.87, Python 3.14.5). Reproduced independently twice, with both generate model and generate crud.

Repro

tina4 init python todoapi && cd todoapi
tina4 generate crud Todo

Expected

The generated migration creates every column the generated model declares.

Actual

Model (src/orm/Todo.py):

id         = IntegerField(primary_key=True, auto_increment=True)
name       = StringField()
created_at = DateTimeField()

Migration (migrations/<ts>_create_todo.sql):

CREATE TABLE IF NOT EXISTS todo (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    created_at TEXT DEFAULT CURRENT_TIMESTAMP
);

name is absent. After tina4 migrate, the first authenticated write fails:

POST /api/todos  ->  HTTP 500
[ERROR] Todo.save() failed for table "todo": table todo has no column named name
[ERROR] Route error: "bool" object has no attribute "to_dict"

Two defects stacked

1. The generator drops the model's declared fields from its DDL. generate auth does NOT have this bug (the users table is complete), so it looks specific to model/crud generation.
2. The generated route does item = Todo.create(...) then item.to_dict() with no check that create() succeeded, so a clean DB error surfaces as an unrelated AttributeError. The 500 hides the real cause.

Why this is high priority

https://tina4.com/llms.txt tells AI assistants to build REST APIs via generate auth + generate crud <Name>. That documented path currently 500s on the first write. I have added a temporary warning to llms.txt; it should be removed once this is fixed.

Per the parity rule this needs checking on php/ruby/nodejs generators too.

[andrevanzuydam]

Fixed in Python (tina4-python@721f308 on v3), not released - holding for parity.

Root cause

Without --fields, _gen_model wrote a model declaring name (a fallback that lived only in the model template) while _gen_migration built its DDL from the parsed field list, which was empty. Three separate ["name"] fallbacks existed; the migration had none. Now a single _fields_or_default() feeds the model, migration, template and co-emitted test.

Also hardened the generated routes: create()/save() return False on failure and never raise, so Model.create(...).to_dict() was turning a clean DB error into bool object has no attribute to_dict.

Verified

• Regression tests fail without the fix (4 of 5) and pass with it; the 5th is a positive control (--fields path, never broken).
• Real end-to-end through the CLI, not just unit tests: fresh tina4 init python + tina4 generate crud Todo now emits a migration containing name.
• Full generator suites green (81 passed).

PARITY - same bug confirmed in 2 more frameworks

tina4-nodejs packages/cli/src/commands/generate.ts:

} else { fieldLines.push(`    name: { type: "string" as const },`); }   // model gets name
generateMigration(`create_${table}`, flags, fields.length > 0 ? fields : undefined, table, false);  // migration gets undefined

tina4-ruby lib/tina4/cli.rb:

field_lines << "  string_field :name"                       # model gets name
generate_migration("create_#{table}", flags, fields_override: fields, ...)   # fields is []
# line 1524: fields = fields_override || parse_fields(...)
# [] is TRUTHY in Ruby, so the || fallback never fires -> no columns

tina4-php not yet checked.

Note the shared blind spot: every generator test in all four frameworks passes --fields explicitly, so the no-fields default path was never exercised anywhere. Worth adding the no-fields case to each suite alongside the fix.

[andrevanzuydam]

PHP checked - also affected, so this is all four frameworks.

bin/tina4php:1609 defaults the model to public string $name = ... while :1643 passes the empty $fields to generateMigration.

Parity issues filed:

• generate model/crud without --fields writes a migration missing the model's own fields (500 on first write) tina4-nodejs#38
• generate model/crud without --fields writes a migration missing the model's own fields (500 on first write) tina4-ruby#33
• generate model/crud without --fields writes a migration missing the model's own fields (500 on first write) tina4-php#186

Note: the Python fix landed inside the 3.13.89 release, so Python is fixed and shipped while the other three are still broken. The parity gap is live rather than pending.

[andrevanzuydam]

Fixed in the 3.13.x line and verified on current v3 HEAD. The default field set now lives in one place (DEFAULT_FIELDS / _fields_or_default in tina4_python/cli/__init__.py) and flows into the model, the migration, the template and the test — so a no---fields model that declares name produces a migration DDL that also creates name. Defect #2 is fixed too: the generated write route checks create()/save() before to_dict().

Regression (real, no mocks): tests/test_cli_generate.py::TestGeneratedMigrationMatchesModel — generates without --fields, AST-parses the model's declared fields and the UP migration SQL, asserts every declared field is in the CREATE TABLE DDL. 5 passed on HEAD. Closing as fixed-in-3.13.x.