ores.seeder

ores.seeder owns database-level synthetic test-data generation for ORE Studio. Its job is to emit SQL INSERT populate scripts that load hand-curated test rows into the schema at build time — so local development and CI start from a known, repeatable dataset without depending on real production data.

The first inhabitants are the Acme Corporation datasets, which exercise the domain schema (legal entities, books, portfolios). Future datasets follow the same convention under datasets/<name>/.

The split keeps the two synthetic-data concerns evolving independently — runtime data ships in the binary; seeder output ships as populate scripts loaded at DB setup.

A crafted dataset is hand-curated content committed to disk under datasets/<name>/. Each dataset has:

• One or more JSON files with the actual row data (e.g. country_currency.json — 100 country/currency pairs).
• A model.json "batch driver" listing each artefact as (template, output, source) tuples.
• A dataset_overview.org documenting the dataset (name, version, methodology, contents, see-also).
• Optional companion files (e.g. methodology.txt).

The seeder is thin: seeder.sh delegates to ores.codegen.generator which renders the mustache templates (sql_catalog_populate.mustache, sql_country_populate.mustache, …) against each JSON. Templates *stay in ores.codegen/library/templates/= — the seeder does not own them.

The crafted form covers cases where rows are known and meaningful (an Acme book's currency mapping carries narrative weight). But many test-data needs are volume needs: 10,000 synthetic parties, 1,000 random trades, etc., where the shape matters but the specific values don't.

The codegen entity migrations have been preserving generator_expr column hints (std::string(faker::internet::url()) etc.) on entities, junctions, lookup entities. The synthesised flavour will read an entity overview (e.g. ores.refdata.party.org) and emit a Python+Faker script that produces N rows of SQL inserts. Same pipeline output (SQL populate), different source-of-truth (entity model + Faker hints, not hand-curated JSON).

Not built yet. No active use case forces it; the entity-model generator_expr hints are already in place so the substrate is ready when a use case appears.

• datasets/<name>/*.json — crafted row data, dataset metadata.
• datasets/<name>/model.json — per-dataset batch driver (template → output → source-json).
• projects/ores.codegen/library/templates/sql_*populate*.mustache — the rendering templates (delegated, not owned).

• projects/ores.sql/populate/<name>/*.sql — populate scripts that psql can run to seed the database.

• seeder.sh generate <dataset> — primary CLI; renders all artefacts declared in the dataset's model.json.
• src/seeder.py — thin shim that imports codegen.generator.

• ores.codegen — the renderer, load_data, mustache templates. ores.seeder delegates to it.

• The data tiers — when a table's rows belong in a seeder dataset at all, and which of the other delivery mechanisms takes the tables this component does not.
• ores.synthetic.service — sibling concern (runtime, not file output).
• ores.codegen — the renderer that ores.seeder delegates to.
• Introduce ores.seeder component for database test-data generation — the introduction story.