Database Seeding
Execution Workflow
- Store fixtures as JSON objects or arrays of objects in a dedicated fixtures directory.
- Use
open_fixture() for sync code or open_fixture_async() for async code.
- Create repository instances inside a real session and load fixture records in batches.
- Seed parent tables before child tables and make the process idempotent when possible.
- Wire seeding into startup hooks, dedicated commands, or one-off scripts based on environment needs.
Implementation Rules
- Keep fixture files versioned alongside the application code.
- Use
add_many() or upsert_many() instead of row-by-row inserts for non-trivial datasets.
- Separate development, test, and production seed data explicitly.
- Do not hide seeding in normal request paths.
Example Pattern
product_data = await open_fixture_async(fixtures_path, "product")
await product_repo.add_many([Product(**item) for item in product_data])
await db_session.commit()
Validation Checklist
- Confirm fixture files include all required model fields.
- Confirm seeding can run twice without creating bad duplicates or broken foreign keys.
- Confirm batch operations commit only after the dataset passes validation.
- Confirm framework startup seeding is acceptable for the target environment and data size.
Cross-Skill Handoffs
- Use
advanced-alchemy-cli for dumping fixture data or pairing seeding with migration workflows.
- Use
advanced-alchemy-litestar, advanced-alchemy-fastapi, or advanced-alchemy-flask for framework-specific startup integration.
- Use
advanced-alchemy-repositories when custom seed logic depends on repository helpers.
Advanced Alchemy References