Generate schema DDL and migrations from entity records

[zantvoort]

Storm is code-first: the records are the source of truth and the schema has to match. #211 adds the reverse direction, generating records from an existing database. Nothing goes the other way, so a team that changes a record still writes the DDL by hand and hopes the two agree.

Most of the work is already done. Schema validation walks the record model against a live schema and computes the delta: missing tables and columns, type mismatches, nullability, primary and foreign keys, constraints. Today it reports that delta and stops. Emitting it as DDL turns a diagnostic into a workflow.

Two outputs

Full DDL for a greenfield schema: CREATE TABLE per entity, columns in record component order, primary keys, foreign keys, unique constraints from @UK, sequences where the generation strategy needs them. This is also what a scaffolded project (#326) needs to bring up its first database.

A migration against a live schema: the validation delta rendered as ALTER TABLE statements, written as a timestamped migration file. Flyway and Liquibase layouts cover most projects; plain SQL to stdout covers the rest.

Generated DDL is a starting point to read, edit and commit, never something Storm applies. Storm does not own a migration history table and should not grow one.

Why it belongs with #211

Both directions need the same dialect type-mapping table, read in opposite directions. Built as separate features they will drift, and the failure mode is a round-trip bug: a column type that generation emits one way and introspection reads back as another. One table, exercised both ways, makes the round trip a test rather than a hope. Put it in the same storm-codegen module behind the same Maven plugin and Gradle task.

Notes

• Destructive changes (dropped columns, narrowed types) are emitted commented out or behind an explicit flag. A generator that silently produces DROP COLUMN is a generator nobody runs twice.
• The delta is only as good as validation's coverage; anything validation cannot see (indexes, check constraints beyond what is modeled) stays out of scope and should be stated as such in the docs.
• Round-trip test: generate DDL from a record set, apply it, introspect it back with Generate entity records from an existing database schema #211, and the records should match what was started with.

Tasks

• DDL emit from the record model, dialect-aware, per supported dialect
• Migration emit from the schema validation delta, with destructive changes gated
• Flyway and Liquibase file layouts, plus plain SQL output
• Shared dialect type-mapping table with Generate entity records from an existing database schema #211, exercised in both directions
• Maven plugin goal and Gradle task, alongside the Generate entity records from an existing database schema #211 entry points
• Round-trip test: records to DDL to database to records
• Docs: evolving a schema from the record model